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ABSTRACT 


The  Director  of  Naval  Reserve  and  Commander,  Naval  Reserve 
Force  (CNRF)  are  totally  dependent  on  the  Commanding  Officer, 
Naval  Reserve  Personnel  Center  (NRPC)  and  the  Inactive 
Manpower  and  Personnel  Information  System  (IMAPMIS)  automated 
information  system  for  the  control  of  all  functions  of 
Selected  Reserve  (SELRES)  mobilization  billet  information, 
personnel  billet  assignments,  personnel  pay  and  tracking 
individual  member  retirement  credit.  Although  recently 
converted  from  a  flat  file  system  to  a  relational  database, 
IMAPMIS  does  not  meet  functional  requirements  for  timely 
update  and  correction  of  critical  data.  IMAPMIS 's  poor 
responsiveness  and  lack  of  ad  hoc  query  capability  make  it 
obsolete  and  virtually  unusable  for  SELRES  data.  The  purpose 
of  this  thesis  is  to  examine  the  present  functions  of  IMAPMIS 
and  identify  its  shortfalls.  This  is  followed  by  a 
recommended  alternative  to  establish  a  separate  SELRES 
database,  administered  by  CNRF,  that  will  internally  process 
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I.  INTRODUCTION 


Since  the  beginning  of  automated  data  recording,  Com¬ 
mander,  Naval  Military  Personnel  Command  (NMPC)  has  been 
responsible  for  overall  control  of  records,  file  systems,  and 
databases  that  pertain  to  the  personnel  associated  with  the 
United  States  Navy.  For  active  duty  personnel,  these  files 
are  maintained  in  Washington,  DC  by  NMPC.  For  Naval  Reserves, 
files  are  maintained  under  the  jurisdiction  of  the  Naval 
Reserve  Personnel  Center  (NRPC)  in  New  Orleans,  LA.  Thus, 
NRPC  is  responsible  for: 

1.  maintaining  up-to-date  mobilization  billets  and 
individual  member  training  assignments 

2.  overall  data  collection,  record  maintenance  and 
updates  for  inactive  naval  reserve  personnel 

3 .  provide  accurate  participation/retirement  point  credit 
for  inactive  naval  reserve  personnel,  and  retirement 
point  capture  process 

4.  supply  accurate  drill  and  ACDUTRA  participation  and 
retirement  data  to  the  Naval  Finance  Center  in 
Cleveland  for  Reserve  pay  matters,  and 
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5.  ensuring  accurate,  timely  data  is  available  for 
external  sources  and  formal  reports  to  the  Congress, 
the  Department  of  Defense  as  reguested 

The  automated  system  that  accounts  for  the  maintenance, 
update  and  control  of  these  records  is  the  Inactive  Reserve 
Manpower  and  Personnel  Management  Information  System 
(IMAPMIS).  IMAPMIS  is  the  official  source  of  all  Inactive 
Reserve  Personnel  information  and  is  central  to  all  Naval 
Reserve  components  and  applications. 

Director  of  Naval  Reserve  (OP-095)  and  Commander,  Naval 
Reserve  Force  (CNRF)  are  responsible  for  the  training, 
preparedness  and  actual  mobilization  of  the  Selected  Reserve. 
They  are  dependent  on  NRPC  for  accurate  data  input, 
corrections,  timely  updates  and  information  flows  that  affect 
all  aspects  of  Reserve  personnel  assets.  Until  recently,  this 
reliance  has  been  a  mandated  necessity  since  neither  OP-095 
nor  CNRF  has  had  the  personnel  or  capability  to  maintain  their 
own  data.  However,  once  a  reservist's  record  has  been 
established  within  IMAPMIS  at  NRPC,  CNRF  has  historically 
assumed  responsibility  for  collecting  data  for  Selected 
Reserves.  In  August  1989,  CNRF  implemented  a  new  automated 
database  system  that  enables  all  417  Naval  Reserve  activities 
to  upload  daily  data  transactions  from  their  individual 
databases  to  a  mainframe  at  CNRF  in  New  Orleans,  LA  via 
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nightly  telecommunication  transmissions.  With  this  new  in- 
house  mainframe  data  processing  capability  at  CNRF  and  direct 
link  to  all  field  activities,  it  is  now  possible  for  CNRF  to 
collect,  automate  and  process  data  internally.  Using  standard 
built-in  edit  functions  for  format,  range  and  acceptable 
parameters,  data  is  verified  immediately  (Schwartz,  1989, pp. 49- 
50).  Additionally,  all  data  uploaded  nightly  to  CNRF  is 
processed  on  a  daily  basis  and  errors  resulting  from  database 
inconsistencies  are  transmitted  to  the  field  for  corrections 
the  next  working  day.  By  affording  the  capability  to  collect 
and  input  data  at  its  source,  this  provides  a  significant 
improvement  in  the  timeliness  and  accuracy  of  data.  Within 
IMAPMIS,  errors  that  could  take  as  much  as  sixty  days  to 
identify  and  resolve  can  now  theoretically  be  corrected  in  one 
to  two  days. 

In  view  of  this  recent  capability  at  CNRF,  the  goal  of 
this  thesis  is  to  address  problems  with  IMAPMIS  and  examine 
issues  concerning  the  feasibility  of  establishing  a  separate 
corporate  database  for  the  Selected  Reserve,  independent  of, 
yet  supportive  to  IMAPMIS.  Chapter  I  presents  the  background 
and  history  of  the  current  system  and  introduces  some  of  the 
idiosyncrasies  within  the  Naval  Reserve.  The  second  chapter 
provides  a  description  of  problems  and  shortfalls  of  existing 
data  flow  architectures,  extensive  data  passing  among  systems, 
and  how  these  factors  impact  on  the  Naval  Reserve  Force. 
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Chapter  III  describes  policy  issues  and  additional 
considerations  that  must  be  addressed  before  additional  time 
and  effort  are  expended  for  the  improvement  of  IMAPMIS  and 
chapter  IV  suggests  an  improved  data  flow  architecture  to 
support  a  separate  Naval  Reserve  database  independent  of  the 
present  NRPC/NMPC  database.  Chapter  V  will  provide 
conclusions  and  recommendations  to  further  enhance  the 
usefulness  and  quality  of  this  independent  database. 

A.  BACKGROUND 

A  first  consideration  to  examining  the  scope  and  ramifi¬ 
cations  of  this  initiative  requires  a  basic  understanding  of 
the  organizational  structure  of  the  Selected  Reserve.  The 
Naval  Reserve  is  comprised  of  personnel  assets  available  to 
the  Navy  in  the  event  of  total  or  partial  mobilization. 
Inactive  Naval  Reserve  Personnel  are  functionally  divided  into 
two  broad  segments.  The  first  segment  consists  of 
approximately  131,000  men  and  women  who  participate  in  monthly 
training  at  one  of  the  417  drill  sites  and  participate  in 
annual  two-week  Active  Duty  for  Training  (ACDUTRA) .  This  pool 
of  personnel  is  managed  by  the  Commander,  Naval  Reserve  Force. 
The  second  group,  managed  by  Commander,  Naval  Reserve 
Personnel  Center,  is  comprised  of  personnel  who  have  completed 
all  of  their  individual  reserve  commitments  and  do  not 
participate  as  drill  deck  assets.  Collectively,  there  are 
actually  six  categories  of  these  personnel,  and  each  is 
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briefly  described  below.  Figure  1  shows  the  categories , 
management  responsibilities  and  approximate  numbers  of 
members . 

1 .  Ready  Reserves 

Ready  Reserves,  more  commonly  known  as  Selected 
Reserves  (SELRES)  or  drilling  Reserves.  These  Reservists 
normally  drill  one  weekend  per  month  and  participate  in  Active 
Duty  for  Training  ( ACDUTRA )  for  two  weeks  each  year.  Their 
participation  is  recorded  and  accumulated  in  a  point  system 
on  an  annual  year  basis.  These  points  are  used  to  determine 
whether  an  individual  SELRES  has  attained  a  satisfactory 
points  total  for  a  "good  year"  of  Reserve  participation.  As 
with  active  duty,  a  Reservist  must  accrue  20  years  of 
satisfactory  service  to  be  eligible  for  retirement. 

2.  Individual  Ready  Reserves 

Individual  Ready  Reserves  (IRR)  may  fill  individual 
military  manpower  requirements  due  to  their  special  training, 
skills  or  professional  qualifications  (e.g.,  surgeons).  They 
may  accrue  credit  for  Reserve  participation  without  actually 
attending  drills.  They  receive  pay  for  their  service,  and 
are  eligible  for,  but  not  required  to  participate  in  ACDUTRA. 

3 .  Standby  Reserves 

Standby  Reserves  are  classified  into  two  subgroups, 
the  Active  Standby  Reserves  (SI  status)  and  the  Inactive 
Standby  Reserves  (S2  Status). 
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RESERVE  PERSONNEL  CATEGORIES 


Category  Managed  By 


SELRES  — | 

Ready  Reserves _ |  CNRF 


Number 

131,000 


IRR 

Individual 
Ready  Reserves 

Standby 
Reserves 
SI  and  S2 


Fleet 

Reserves 

Retirees 

New 

Accessions 


NRPC 


619,000 


Total 


750,000 


Figure  1.  Reserve  Personnel  Categories 


Active  Standby  Reserves  (SI  status)  are  personnel  who 
are  eligible  for  promotion  and  may  drill  in  a  non-pay  status. 
They  may  also  complete  Navy  Training  Courses  for  participation 
and  retirement  point  credit.  However,  they  are  not  eligible 
for  ACDUTRA. 

Inactive  Standby  Reserves  (S2  status)  are  not  eligible 
to  participate  in  drills,  are  not  eligible  for  promotion  and 
may  not  accrue  retirement  point  credit.  They  may,  however 
move  back  to  SI  Status  by  signing  a  Ready  Reserve  Service 
Agreement . 

4 .  Fleet  Reserves 

Rather  than  being  retired,  enlisted  members  who  have 
completed  a  minimum  of  20  years  service  either  on  active  duty 
or  in  the  Reserves  are  transferred  to  the  Fleet  Reserves  for 
a  period  of  up  to  ten  years  or  30  years  total  service.  They 
may  voluntarily  participate,  but  may  not  accrue  additional 
retirement  point  credit.  They  are  eligible  for  recall. 

5 .  Retirees 

Retirees,  both  USN  and  USNR  are  considered  in  an 
inactive  status.  They  may  voluntarily  participate  in  a  non¬ 
pay  status,  but  cannot  receive  additional  retirement  point 
credit.  They  are  eligible  for  recall  during  mobilization. 
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6.  New  Accessions 


New  accessions  from  Volunteer  and  Selective  Service 
Draft  Categories  may  be  pretrained  or  untrained  assets 
mobilized  from  the  civilian  sector. 

In  total,  the  Inactive  Naval  Reserve  Component  consists 
of  more  than  750,000  personnel  and  their  associated  service 
and  medical  records.  Maintaining  these  records  requires  a 
tremendous  amount  of  data  that  must  be  updated  and  verified 
to  ensure  that  adr^uate  personnel  resources  are  ready  to 
support  and  defend  the  United  States .  In  the  event  of 
mobilization,  Reserve  assets  will  be  matched  against 
predetermined  mobilization  billet  requirements  of  active  duty 
commands.  The  billets  and  mobilization  requirements 
themselves  are  compiled  by  the  Chief  of  Naval  Operations 
( OPNAV )  using  the  classified  Naval  Manpower  Data  Accounting 
System  (NMDAS) .  Unclassified  reserve  billet  information  is 
subsequently  passed  through  the  IMAPMIS  system  where  reports 
are  produced  for  CNRF  on  the  Reserve  Unit  Manpower 
Authorization  System  (RUMAS).  These  reports  are  used  for 
manual  structuring  Reserve  Units.  Once  structured,  the  data 
is  returned  to  NRPC  for  input  into  IMAPMIS. 

This  thesis,  in  examining  the  establishment  of  a  separate 
SELRES  database,  will  concentrate  on  the  portion  of  the  NRPC 
corporate  database  that  directly  concerns  the  Ready  Reserve 
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(SELRES)  that  fall  under  the  jurisdiction  of  the  Commander, 
Naval  Reserve  Forces  for  training  and  mobilization. 

B.  HISTORY  OF  IMAPMIS 

The  master  files  for  all  Naval  Reserve  personnel,  as 
previously  stated,  are  maintained  by  the  Commander,  Naval 
Reserve  Personnel  Center  in  New  Orleans,  LA.  However,  until 
April  1989,  the  ADP  management  for  these  records,  files  and 
recently  converted  database  was  the  responsibility  of  the 
Naval  Military  Personnel  Command,  NMPC-9,  Director /Special 
Assistant  for  Naval  Reserve  Matters  (with  dual  responsibility 
as  OP-OIR) .  This  office,  located  in  Washington,  DC  and 
physically  separate  from  NRPC,  is  the  command  responsible  for 
running  the  system. 

IMAPMIS  today  is  a  conglomeration  of  smaller  systems  whose 
origins  can  be  traced  back  to  the  Naval  District  organization. 
Its  functionality  has  evolved  minimally  since  its  inception 
in  the  mid-1970s  at  the  Naval  Training  Center  in  Bainbridge, 
MD.  However,  its  efficiency  has  diminished  significantly  as 
the  system  has  migrated  through  seven  different  hardware 
suites  during  its  lifetime.  Initially  a  batch-oriented 
sequential  file,  tape  system  fed  by  punched  cards,  IMAPMIS  was 
designed  to  update  Naval  Reserve  personnel  data  on  a  monthly 
basis  and  to  report  mobilization  billet  requirements  on  a 
quarterly  basis.  As  recently  as  1981,  the  data  collected  at 
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NRPC  was  sent  to  Washington,  DC  where  it  was  processed  on  the 
OP-01  mainframe  computer.  Due  to  the  massive  volume  of 
approximately  750,000  records,  a  typical  monthly  update  run 
required  a  minimum  of  seven  days  to  process.  The  quarterly 
mobilization  requirement  file  updates  from  active  duty  inputs 
required  an  additional  25  hours  of  processing  time  (IMAPMIS 
SDP  1,1983).  Any  errors  identified  during  the  monthly 
processing  were  returned  to  the  local  Naval  Reserve  Activity 
(NRA)  for  correction.  The  monthly  processing  schedule  caused 
inordinate  time  delays  in  error  detection  and  correction,  and 
could  prevent  a  SELRES  from  receiving  drill  pay  for  two  to 
three  months.  Another  significant  problem  involved  accurate 
identification  of  current  mobilization  billets.  SELRES 
Personnel  Mobilization  Teams  (PMT) ,  who  are  responsible  for 
the  initial  mobilization  of  Naval  Reserve  IRR  assets,  found 
it  impossible  to  accurately  identify  valid  billets.  At  any 
given  time,  the  mobilization  billet  listings  available  to  the 
PERSMOB  Teams  could  be  three  months  old  and  created  confusion 
resulting  from  inaccurate  readiness  information  during  recall 
and  mobilization  exercises. 

In  regard  to  the  state  of  IMAPMIS  in  1981  and  its  impact 
on  the  SELRES  and  NRPC: 

The  Naval  Reserve  Personnel  Center  cannot  properly  perform 
its  mission  with  regard  to  maintenance  of  current, 
accurate,  timely  personnel  files,  support  for 
mobilization,  or  provision  of  scheduled  and  ad  hoc  reports 
to  DOD  and  DON  users.  The  monthly  update  cycle  provides 
data  which  is  in  a  range  of  45  -  65  days  old  by  the  time 
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the  information  is  available  to  users.  In  case  of  data 
exceptions  a  minimum  of  an  additional  30  days  must  be 
added.  As  a  result  . . .  managers  of  Inactive  Personnel 
will  continue  to  make  major  management  and  policy 
decisions  based  on  inaccurate ,  invalid  and  non-current 
information  or  no  information  at  all.  (IMAPMIS  MENS,  1981) 

In  October  1981,  out  of  desperation,  the  Chairman  of  the 
National  Naval  Reserve  Policy  Board  specifically  addressed  the 
shortfalls  of  IMAPMIS  in  a  memorandum  (NNRPCB  Memo, October 
1981)  to  the  Chief  of  Naval  Operations.  He  complained  of  the 
overall  "inadequacy  of  computer  support  for  Naval  Reserve 
manpower  and  personnel  administration."  The  memo  requested 
corrective  actions  be  undertaken  immediately  to  alleviate  the 
inability  of  the  Naval  Reserve  to  quickly  restructure  Selected 
Reserve  Mobilization  billets  among  Naval  Reserve  Activities 
to  match  changes  implemented  by  active  duty  commands.  This 
problem  directly  contributed  to  improper  structuring  of 
Reserve  Units  and  often  reflected  a  misrepresentation  of  the 
training  levels  of  personnel  assigned  to  these  units. 

A  second  immediate  problem  addressed  in  the  memo  concerned 
the  inadequacy  of  IMAPMIS  to  maintain  accurate  personnel 
records  and  its  inability  to  provide  fast  accurate  drill 
reporting  error  feedback  to  NRAs.  The  memo  proposed  that  if 
errors  were  detected  early  and  information  provided  to  tho. 
activities,  corrections  could  be  submitted  prior  to  the  actual 
data  transfer  to  the  Naval  Finance  Center,  Cleveland,  OH. 
This  would  significantly  enhance  the  generation  of  accurate 
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and  timely  ACDUTRA  and  monthly  drill  pay.  In  the  existing 
environment,  errors  in  drill  reporting  were  not  detected  until 
the  data  tapes  were  processed  on  hardware  physically  located 
in  Bratenol,  OH  and  resulted  in  inordinate  delays  in 
processing  pay  checks. 

As  a  result  of  repeated  complaints  of  this  nature,  it  was 
decided  that  IMAPMIS  should  be  redesigned  and  converted  from 
the  archaic  batch,  transaction-oriented  system  to  a  relational 
data  base  management  system  (DBMS).  The  Mission  Element  Needs 
Statement  (MENS)  for  the  conversion  of  IMAPMIS  was  submitted 
on  15  July  1981  by  NMPC-92,  and  the  first  version  of  the  new 
relational  database  was  put  on  line  in  April  1989.  The 
IMAPMIS  redesign  effort,  starting  with  Milestone  0  approval 
in  September  1981,  was  followed  by  Milestone  I  approval  in 
January  1983,  and  Milestone  II  approval  in  January  1989.  The 
"redesign"  as  it  is  commonly  referred  to,  did  not  modify  or 
enhance  the  operations,  interfaces  or  functionality  of 
IMAPMIS,  but  merely  transposed  the  flat  file  batch  records 
into  a  relational  database.  Meanwhile,  over  the  9  years  of 
development  and  transition,  requirements  for  IMAPMIS  to 
provide  more  accurate  and  timely  information,  and  needs  for 
ad  hoc  management  reports  have  grown  exponentially.  Future 
anticipated  reporting  requirements  of  IMAPMIS  also  indicate 
that  the  system,  already  taxed  beyond  its  capabilities,  will 
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soon  be  unable  to  provide  even  the  most  basic  requirements  of 
the  Commander,  Naval  Reserve  Force. 

Over  a  span  of  the  past  twenty  years,  IMAPMIS  has  been 
shuffled  from  one  computer  hardware  suite  to  another  without 
any  effort  to  redesign  or  develop  new  functionality  capable 
of  taking  advantage  of  increasingly  sophisticated  hardware 
and  software  environments.  Simultaneously,  internal  and 
external  demands  and  requirements  for  timely,  accurate,  up- 
to-date  information  have  increased  significantly.  Yet  the 
"redesigned"  IMAPMIS  remains  an  archaic  system  that  does  not 
meet  the  current  requirements  of  today's  fast-paced  world  and 
need  for  ad  hoc  management  reports.  Problems  abound  with  the 
accuracy  of  reserve  unit  structure,  personnel  records  and  the 
drill  reporting  system  that  authorizes  SELRES  pay.  Inputs  to 
IMAPMIS  are  still  designed  around  a  flat-file  diary  entry 
mentality  and  data  tapes  are  bulk  data  transferred  for 
relatively  low  priority  bi-monthly,  processing  on  the  hardware 
at  the  Consolidated  Data  Center  (CDC)  in  Bratenol,  OH. 
Converting  IMAPMIS  to  a  relational  database  resulted  in  only 
limited  improvements  in  processing  times.  However  without 
functional  enhancements  to  help  managers  keep  pace  with  the 
most  urgent  requirements,  IMAPMIS  performance  has  degraded  to 
a  level  considered  totally  unacceptable  to  the  Commander, 
Naval  Reserve  Force.  (CNRF  letter, 7  November  1989)  (CNRF 
letter, 10  November  1989) 
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IMAPMIS  was  then  and  is  now  an  antiquated,  inefficient 
system  unresponsive  to  user  requirements.  The  goal  of  this 
thesis  is  to  examine  the  specific  problems  encountered  by  CNRF 
in  using  IMAPMIS  as  its  corporate  database,  and  then 
subsequently  to  explore  the  feasibility  of  creating  a  separ¬ 
ate  SELRES  database  controlled  by  CNRF  for  SELRES.  It  is 
proposed  that  this  new  database  may  help  streamline  the 
existent  data  flow  architectures  and  eliminate  unnecessary 
data  passing  and  duplicate  edit  checks  among  systems. 
Finally,  it  will  provide  a  comparison  of  the  advantages  and 
disadvantages  of  each  system  from  the  CNRF  and  SELRES 
perspective . 
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II.  FUNCTIONAL  AND  OPERATIONAL  DESCRIPTION  OF  IMAPMIS 


As  a  system,  IMAPMIS  is  a  highly  complex  entity  that  is 
interdependent  on  other  systems  and  inter-organizational  by 
nature.  It  exchanges,  passes  and  processes  data  that  crosses 
both  functional  and  organizational  boundaries.  IMAPMIS 
supports  all  six  categories  of  Naval  Reserve  personnel 
discussed  in  chapter  I.  It  involves  the  collection,  proces¬ 
sing,  maintenance  and  dissemination  of  all  data  regarding 
Inactive  Naval  Reserve  personnel.  It  is  described  as: 

...the  official  source  of  all  Inactive  Reserve  Personnel 
information  and,  as  such,  ...is  central  to  all  other 
Reserve  Component  application  modules  which  either  pass 
data  to  it  or  receive  data  from  it,  or  both.  Addition¬ 
ally,  it  is  responsible  for  providing  key  personnel  and 
drill  attendance  data  to  the  Navy  Finance  Center,  Cleve¬ 
land  for  financial  accounting  purposes  and  a  total  monthly 
personnel  extract  to  DOD.  All  official  inactive  personnel 
and  drill  transactions  must  flow  into  the  IMAPMIS  system 
and  all  scheduled  or  ad  hoc  reports  or  file  extracts  are 
generated  from  it.  (IMAPMIS  MENS, 1981) 

With  such  a  large  and  varied  population  to  support,  the 

functional  requirements  of  IMAPMIS  are  complex  and  differ 

greatly  according  to  the  personnel  category  being  supported. 

In  this  chapter,  the  functions  of  the  IMAPMIS  will  be 
delineated  and  the  individual  command  relationships  and  their 
respective  responsibilities  discussed.  This  will  be  followed 
by  a  synopsis  of  the  many  systems,  subsystems  and  files 
belonging  to  IMAPMIS.  Additionally,  the  major  inputs,  outputs 
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and  overall  system  data  flow  architecture  and  IMAPMIS 
interfaces  with  other  systems  will  be  examined.  The  final 
section  of  the  chapter  will  discuss  some  of  the  more 
significant  shortfalls,  and  the  impact  that  these  problems 
impose  on  the  SELRES  community  and  CNRF  will  be  discussed. 
The  first  aspect  of  IMAPMIS  that  will  be  addressed  involves 
the  system  functionality. 

A.  IMAPMIS  FUNCTIONALITY 

IMAPMIS  provides  many  functions  for  Inactive  Naval  Reserve 
Personnel,  as  well  as  for  external  commands  such  as  the 
Director  of  Naval  Reserve  (OP-095),  CNRF,  OPNAV,  NRPC.  In 
many  ways,  it  replicates  or  mirrors  similar  active  duty 
systems,  particularly  in  respect  to  personnel  data  collection, 
processing  and  information  storage.  However,  IMAPMIS  is 
tasked  with  many  additional  functions  that,  within  the  active 
duty  environment  are  performed  by  separate  commands  with 
independent  systems.  The  conglomeration  of  these  disparate 
functions  into  a  single  monolithic  system,  have  made  IMAPMIS 
a  highly  complex  entity  where  organization  responsibilities 
are  vague  and  difficult  to  trace.  It  is  even  more  difficult 
to  ascertain  the  exact  origin  of  data  elements  or  the  source 
of  data  errors.  The  result  is  a  system  that  essentially  runs 
the  users  rather  than  allowing  the  users  to  run  the  system  or 
a  prime  example  of  the  tail  wagging  the  dog. 
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From  a  general  perspective,  IMAPMIS  is  comprised  of 
essentially  four  major  functions.  These  may  be  further 
subdivided  for  better  understanding,  however  they  are  prima¬ 
rily  related  to: 

1.  Mobilization  Billet  information,  Reserve  Unit  Billet 
Structures,  and  SELRES  assignments  to  billets 

2.  SELRES  drill  and  ACDUTRA  participation  data  capture 
and  storage 

3.  Personnel  records  and  data  update,  and 

4.  Transfer  of  personnel  data  between  active  and  inactive 
personnel  systems 

The  primary  objective  of  IMAPMIS  is  to  manage  the  Naval 
Reserve  database.  This  database,  the  official  source  of  all 
Naval  Reserve  personnel  data  is  a  major  subcomponent  of  the 
NMPC  Manpower,  Personnel  and  Training  Information  System 
(MAPTIS)  and  contains  critical  data  concerning  both 
mobilization  billets  and  the  Inactive  Naval  Reserves  who  will 
fill  them.  Although  it  supports  all  categories  of  reserve 
personnel,  this  chapter  will  focus  on  functions  that  are 
specific  to  the  SELRES  community. 

Interestingly,  SELRES  personnel  comprise  only  about  18% 
of  the  total  Inactive  Reserve  population,  yet  transactions 
supporting  SELRES  personnel  account  for  an  overwhelming 
majority  of  data  inputs  and  updates  at  and  through  NRPC.  A 
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check  of  NRPC  manual  transaction  logs  revealed  that  during  the 
month  of  September  1989  approximately  60,000  transactions  were 
hand-keyed  updating  IMAPMIS.  Of  these  transactions,  over  65% 
were  estimated  to  pertain  to  SELRES. 

1.  Mobilization  Billet  Requirements 

Perhaps  the  single  most  important  function  of  IMAPMIS 
is  to  provide  the  Commander,  Naval  Reserve  Force  (CNRF)  with 
current,  frequent  updates  of  reserve  billet  requirements. 
Once  the  billet  requirements  are  generated  on  RUMAS  and 
printouts  are  provided  to  CNRF ,  they  are  then  used  to 
structure  these  billets  into  Naval  Reserve  Units  to  which 
SELRES  personnel  will  be  assigned.  Training  requirements  are 
established  with  the  ultimate  goal  of  being  able  to  provide 
adequate  numbers  of  pre-trained  SELRES  personnel  to  fill 
active  duty  billets  in  the  event  of  mobilization.  Current  and 
accurate  reporting  of  active  duty  requirements  enhances  the 
ability  of  CNRF  to  properly  structure  Reserve  Units  among  its 
417  training  sites  and  its  ability  to  provided  for  the  most 
efficient  use  of  both  training  and  personnel  resources. 
IMAPMIS,  by  functional  description  must  be  capable  of  allowing 
preassignment  of  over  200,000  SELRES  within  an  environment 
where  over  half  of  these  assignments  normally  change  over  a 
three-year  period.  In  the  event  of  mobilization,  IMAPMIS 
should  also  support  the  assignment  and  activation  of 
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approximately  30,000  personnel  in  the  course  of  any  single 
week. 

2.  Individual  Participation  Credit 

Another  major  function  of  IMAPMIS  is  to  collect  and 
maintain  all  Inactive  Naval  Reserve  participation  data.  The 
total  number  of  points  that  each  individual  officer  earns  and 
the  reason  they  were  awarded  is  collected  and  summarized  on 
annual  basis.  (Enlisted  data  are  still  recorded  manually  and 
plans  are  to  incorporate  this  function  in  phase  two  of  the 
IMAPMIS  redesign.)  The  reservist's  anniversary  date  is  used 
as  the  basis  for  this  point  capture.  The  summation  of  these 
points  determines  the  members  retirement  eligibility.  Points 
are  earned  for  drill  completions,  Acti%e  Duty  for  Training 
( ACDUTRA )  completion,  credit  for  completion  of  training 
courses  and  credit  for  any  pre-reserve  or  other  extended 
periods  of  active  duty.  NRPC  is  responsible  for  accurate  and 
timely  update  of  individual  SELRES  participation  and 
retirement  points  as  well  as  maintaining  current  point 
captures  for  all  Inactive  Naval  Reservists.  These  point 
totals  and  certification  of  retirement  eligibility  are  passed 
to  the  Navy  Pay  and  Personnel  System  (PAYPERS)  and  NFC  for 
disbursement  of  retirement  pay. 

A  function  parallel  to  tracking  the  ACDUTRA  and  drill 
participation  for  SELRES  provides  accounting  and  financial 
data  status  to  OP-095  for  the  purpose  of  managing  the  Reserve 
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Personnel  Navy  (RPN)  appropriation.  The  annual  RPN 
appropriation  is  the  allowance  of  funds  from  which  SELRES  and 
active  duty  support  personnel  are  paid.  The  total 
expenditures  must  be  monitored  closely  by  OP-095  to  preclude 
exceeding  congress ionally  mandated  authorization  levels. 

3.  Personnel  Records  and  Data  Update 

IMAPMIS  serves  as  the  master  repository  of  all 
Inactive  Naval  Reserve  personnel  data  (service  and  medical 
records).  In  this  capacity,  NRPC  is  tasked  with  maintaining 
and  updating  this  data  as  well  as  providing  collected  data  to 
external  systems  in  pre-programmed  and  limited  ad  hoc  formats. 
Critical  data  items  such  as  officer  promotional  status, 
individual  drill  status,  paygrade/rank  information  and  current 
address  files  are  maintained.  Other  important  elements  such 
as  names  of  beneficiaries,  and  next  of  kin  are  maintained. 
It  is  vital  that  members'  personnel  data  are  correct  and 
updated  in  a  timely  manner.  Errors  can  drastically  affect 
reported  strengths,  training  levels  and  SELRES  pay. 

4 .  Data  Transfer 

Finally,  IMAPMIS  allows  for  the  transfer  of  personnel 
data  to  and  from  active  duty  systems.  Through  data  updates 
from  NMPC,  IMAPMIS  and  NRPC  receive  records  of  individuals  who 
are  being  released  from  active  duty  and  transferred  to  the 
Inactive  Naval  Reserve.  Conversely,  IMAPMIS  must  also  provide 
personnel  records  and  data  to  active  duty  systems  for 
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personnel  who  either  terminate  their  reserve  commitments  and 
return  to  active  duty  or  are  recalled  for  extended  periods  of 
active  duty.  This  particular  functionality  will  become 
critical  in  the  event  of  mobilization  where  massive  numbers 
of  personnel  records  must  update  active  duty  systems.  Errors 
in  data  will  adversely  affect  mobilization. 

It  is  estimated  that  IMAPMIS  generates  approximately  433 
cyclical  reports  and  is  relied  upon  as  the  sole  source  of 
support  for  over  500  non-standard,  ad  hoc  management  inquiries 
per  year.  The  capability  to  expand  IMAPMIS  in  order  to 
satisfy  ever-increasing  demands  in  compliance  with  DOD  and 
Congressional  information  demands  is  severely  limited. 
Improvements  to  IMAPMIS  anticipated  in  the  follow-on  stages 
of  the  redesign  project  include  a  review  of  all  system  outputs 
and  output  methods.  All  existing  programs  will  be  replaced 
by  new  applications  and  an  enlisted  automated  participation 
point  capture  system  will  be  developed.  (IMAPMIS  SDP  111,1989) 

However,  the  conversion  project  to  date  has  exceeded  cost 

projections  by  $1,589,761  and: 

When  compared  to  the  schedule  provided. .. it  is  apparent 
that  this  project  fell  well  behind  projections.  This 
reflects  funding  limitations,  restrictions  placed  on  the 
ADP  project  manager  by  unforseen  and  unforeseeable  even¬ 
ts,  procurement  delays,  and,  to  some  degree  over-op¬ 
timistic  projections.  (IMAPMIS  SDP  111,1989) 

Additionally,  SELRES  constitute  only  33%  of  the  total 
record  maintenance  responsibility  of  IMAPMIS  and  error 
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corrections  and  updates  account  for  over  17%  of  all  data 
inputs  to  IMAPMIS.  This  reflects  a  tremendous  manpower 
requirement  for  input  of  data.  Development  of  new  programs 
that  will  support  interactive  input  update  is  only  one  of  many 
high-priority  enhancements  required  for  future  development. 
In  the  present  environment  of  budget  reductions  and  the 
intense  congressional  interest  in  large  centralized  Automatic 
Data  Processing  (ADP)  and  software  development  projects  it  is 
uncertain  when  or  even  if  these  enhancements  will  be  approved 
and  become  operational. 

B.  COMMAND  RELATIONSHIPS  AND  RESPONSIBILITIES 

In  addition  to  having  a  firm  grasp  of  the  overall 
functionality  of  IMAPMIS,  one  must  also  understand  the 
interoperability  and  complex  inter-command  relationships  and 
responsibilities  associated  with  IMAPMIS.  To  actually  support 
the  previously  discussed  processes,  IMAPMIS  must  provide 
operational  interfaces,  either  direct  or  indirect,  with 
internal  and  external  systems.  These  interfaces  create  unique 
and  often  conflicting  requirements  within  the  system.  It  is 
almost  impossible  to  ascertain  the  origin  of  a  data  element 
or  produce  an  audit  trail  depicting  the  location  and  time  of 
the  most  recent  update.  As  can  be  imagined,  "The  problem  of 
maintaining  high  quality  records  in  an  information  system  is 
magnified  in  an  inter-organizational  computer  system." 
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(Laudon, January  1986).  The  same  data  may  be  used  for  several 
different  purposes  at  differing  management  levels.  The 
quality  and  timeliness  of  the  data  also  differs  among  the 
users ,  making  it  virtually  impossible  to  specifically  define 
the  requirements  of  the  system.  Many  of  the  processes  that 
generate  information  and  reports  use  inputs  that  are  outputs 
from  other  processes.  Subsequently,  errors  in  the  original 
data  items  may  be  altered,  modified  and  further  corrupted. 

The  following  sections  list  the  major  command  relation¬ 
ships  of  IMAPMIS  along  with  a  very  brief  synopsis  of  the 
informat  ion/data  required  by  each  and  at  what  level  and  manner 
the  data  is  used.  As  can  be  seen,  the  levels  of  interaction 
and  type  of  data  provided  among  these  systems  varies 
dramatically.  Figure  2  provides  an  overall  view  of  the 
individual  commands  and  organizations  that  depend  on  or 
utilize  IMAPMIS  data. 

1.  Chief  of  Naval  Personnel  (0P-01)  -  Washington,  DC 
The  Deputy  Chief  of  Naval  Operations  (Manpower, 
Personnel  and  Training)  provides  ADP  hardware,  software  and 
facilities  in  Washington,  DC  in  support  for  IMAPMIS.  A 
subordinate  code,  OP-16  is  also  responsible  for  establishing 
and  enforcing  data  element  and  Navy  Live  Cycle  Management 
standards . 
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COMMAND  HIERARCHY 


Figure  2.  Command  Hierarchy 
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2.  Chief  of  Naval  Operations  (OP-095)  -  Washii.^ton,  DC 
The  Director  of  Naval  Reserve,  under  the  direction  of 

the  Chief  of  Naval  Operations,  provides  periodic  compilations 
of  mobilization  billet  requirements  to  IMAPMIS.  This  billet 
data  is  passed  to  IMAPMIS  from  NMD AS  at  OPNAV.  IMAPMIS  would 
then  generate  hard  copy  reports  that  were  delivered  to  the 
Commander,  Naval  Reserve  Force  headquarters  for  the  purpose 
of  determining  the  manpower  structure  of  the  reserve  units. 
This  relationship  is  expected  to  change  in  June  of  1990  and 
the  billet  data  will  be  provided  directly  from  OPNAV * s  NMD AS 
system  to  CNRF's  new  Reserve  Training  Support  System  (RTSS) 
through  direct  interface. 

3.  Naval  Military  Personnel  Command  -  Washington,  DC 
Naval  Military  Personnel  Command  (NMPC)  establishes, 

implements  and  administers  policies  for  assignment,  retention, 
separation  and  discharge  of  inactive  Naval  Reservists.  These 
functions  are  accomplished  through  direct  liaison  with  its 
subordinate  command,  NRPC  and  indirectly  with  OP-095  and  CNRF. 
NMPC  provides  personnel  data  to  IMAPMIS  through  the  Officer 
Personnel  Information  System  (OPINS)  and  the  Naval  Enlisted 
System  (NES)  and  the  Source  Data  System  (SDS).  Additionally, 
NMPC-9/OP-01R  requires  access  to  IMAPMIS  to  determine  officer 
promotion  history  and  eligibility  using  the  Inactive  Officer 
Promotion  Administrative  System  ( IOPAS ) .  In  this 
relationship,  NMPC-9,  the  inactive  reserve  counterpart  to 
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NMPC-2  for  active  duty  personnel,  convenes  all  reserve  officer 
promotion  boards  and  updates  officer  promotional  status  at  the 
conclusion  of  each  board  using  the  Inactive  Officer 
Administrative  Promotion  System  (IOPAS).  It  is  imperative 
that  IMAPMIS  reflect  accurate  data  such  as  date  of  rank  and 
proper  designator.  Incorrect  information  may  inadvertently 
preclude  an  otherwise  eligible  officer  from  promotion.  It  is 
equally  important  that  promotion  updates  entered  by  NMPC  into 
IOPAS  properly  update  the  promotional  history  file. 

4.  Naval  Reserve  Force  -  New  Orleans,  LA 

Commander,  Naval  Reserve  Force  (CNRF)  is  responsible 
for  structuring  Reserve  Units  from  mobilization  billet 
requirements  provided  from  NMDAS  at  OPNAV.  Structuring 
billets  into  units  involves  accessing  total  billet  require¬ 
ments  and  matching  needs  against  available  SELRES  assets.  By 
optimizing  matches  between  SELRES  assets  and  billet 
requirements,  CNRF  can  maximize  unit  manning,  enhance  train¬ 
ing  levels  and  improve  unit  cohesiveness.  The  goal  is  to 
assign  as  many  SELRES  to  local  units  as  possible  and  to 
eliminate  the  need  to  assign  an  individual  to  a  unit  in  a 
geographical  area  different  them  his/her  home.  Once  the  units 
are  structured,  training  requirements  are  established  after 
the  billets  are  fed  back  into  IMAPMIS  during  the  next 
processing  update.  Only  after  all  these  steps  are  completed, 
and  after  the  new  unit/structure  is  reflected  on  the  hardcopy 
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reports  from  IMAPMIS,  can  CNRF  and  local  Naval  Reserve 
Activities  (NRAs)  assign  SELRES  to  these  billets. 
Presently, the  structuring  process  is  completed  manually  at 
CNRF  from  billet  listings  produced  by  RUMAS.  Unit  structuring 
is  a  difficult,  time  consuming  process.  Without  the  aid  of 
automatic  processing  support  it  is  difficult  to  assess  the 
decisions  determining  unit  size,  placement  and  composition. 
The  direct  data  exchange  from  NMDAS  to  RTSS  anticipated  in 
June  1990  is  now  in  a  testing  phase.  However,  it  is  expected 
that  this  new  interface  will  significantly  expedite  Reserve 
Unit  billet  structuring  process.  Additionally,  a  new  decision 
support  system  is  being  developed  for  RTSS  system  that  will 
significantly  enhance  the  structuring  process.  As  a  result, 
CNRF  should  be  able  to  make  far  better  decisions  regarding 
unit  placement  and  manpower  composition  than  can  be 
accomplished  with  the  manual  procedures  necessary  with 
IMAPMIS. 

An  equally  important  responsibility  of  CNRF  is  to 
effectively  train  and  administer  the  SELRES  community  in 
preparation  for  mobilization.  Once  the  reserve  units  are 
structured  and  manned ,  it  is  necessary  to  monitor  the  level 
of  manning  and  quality  of  training  completed  within  those 
units.  Units  are  assigned  training  and  readiness  status  based 
on  these  training  achievements  and  individual  unit  manning 
levels.  This  data  is  used  both  internally  for  planning  and 
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evaluation  purposes  as  well  as  externally  for  overall  force 
status  reports.  The  accuracy  of  this  data  is  vital  to  an 
accurate  representation  of  the  welfare  of  the  Naval  Reserve. 

5.  Navy  Finance  Center  -  Cleveland,  OH 

The  focal  point  for  active  duty  navy  personnel 
financial  processing,  the  Navy  Finance  Center  (NFC)  also 
accounts  for  all  drill,  ACDUTRA  and  retirement  pay,  based  on 
drill  and  personnel  data  passed  from  IMAPMIS.  Concurrent  with 
the  decision  to  redesign  IMAPMIS  in  1982,  it  was  determined 
that  the  main  IMAPMIS  processes  would  be  run  on  the  CDC  system 
that  supports  NFC,  thus  allowing  the  consolidation  of  all  pay 
processing  for  both  active  duty  and  reserves  on  a  single 
system.  Necessarily,  this  command  relationship  is  critical 
for  SELRES  and  retired  reserves.  Although  few  data  changes 
may  disrupt  retired  pay,  any  number  of  invalid  or  incorrect 
personnel  data  elements  affect  the  timely,  accurate  drill  pay 
of  SELRES  personnel. 

6.  Naval  Education  and  Training  Center  -  Pensacola,  FL 

The  Chief  of  Naval  Education  and  Training  Center 

(CNET)  provides  results  of  correspondence  course  completions 
to  IMAPMIS.  Completion  of  these  courses  by  Naval  Reservists 
adds  to  individual  accumulations  of  Reserve  Retirement 
Participation  Points.  Presently,  the  course  completion 
documents  are  mailed  to  NRPC  where  they  are  hand-keyed  into 
IMAPMIS.  There  is  no  method  to  track  or  validate  inputs  and 
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it  becomes,  by  default,  the  individual's  responsibility  to 
ensure  that  these  points  are  actually  awarded. 

7.  Naval  Reserve  Personnel  Center  -  New  Orleans ,  LA 

Naval  Reserve  Personnel  Center  (NRPC),  a  field  command 
of  NMPC ,  is  responsible  for  maintaining  the  corporate 
personnel  data  base  of  Inactive  Naval  Reserve  Personnel  for 
NMPC.  This  includes  total  management  and  assignment 
responsibility  for  all  Pre-trained  Individual  Mobilization 
(PIM)  assets  ( IRR  personnel ,  standby  reserves,  fleet  reserves, 
and  retirees).  These  personnel  assets  are  totally  independent 
of  CNRF  and  do  not  actively  participate  in  monthly  training 
drills.  NRPC  is  solely  responsible  to  NMPC  for  maintenance 
of  service  records  and  personnel  data. 

In  addition  to  PIM  administration,  NRPC  is  also  tasked 
with  the  production  and  distribution  of  reserve  billet 
requirement,  manpower  and  personnel  reports.  To  support  these 
reporting  requirements,  NRPC  updates  personnel  data  from  and 
for  both  PIM  assets  and  SELRES. 

C.  IMAPMIS  SYSTEMS,  SUBSYSTEMS  AND  FILES 

Within  IMAPMIS  are  several  major  subsystems  and  file 
applications  that  support  the  functionality  and  command 
relationships  described  above.  A  brief  description  of  these 
subsystems,  shown  in  Figure  3,  is  provided  in  the  following 
sections . 
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1.  Inactive  File  Maintenance  System  (IFILMAN) 

IFILMAN  is  the  central  processing  system  in  IMAPMIS 
and  actually  produces  the  updated  files  and  reports.  It 
accepts  data  generated  by  NMP C,  OPNAV,  NRPC,  CNRF  and  reserve 
field  units.  When  processing  runs  are  made,  all  input  data 
is  pre-edited.  These  edits  checks  are  predominantly  for  valid 
change  codes,  postal  addresses  and  zipcodes  and  designators. 
One  estimate  reflected  a  monthly  average  of  200,000  data 
element  updates  to  personnel  records  and  for  approximately 
300,000  drills  (IMAPMIS  SDP  1,1983).  Additionally,  IFILMAN 
processes  and  matches  this  data  against  mobilization  billet 
files.  Rejected  transactions  are  returned  to  NRPC  while  valid 
transactions  update  the  IMAPMIS  master  files. 

2.  Reserve  Unit  Manpower  Assignment  System  (RUMAS) 

CNRF  and  NRAs  vise  RUMAS  outputs  to  manage  the  proper 

mobilization  billet  assignments  of  SELRES.  After  units  are 
authorized  and  established  by  OP-095,  the  units  are  structured 
by  CNRF  and  the  billets  are  filled  by  SELRES.  The 
mobilization  files  include  billet  requirement  data  such  as: 
the  rank  or  rate,  rating  and  applicable  NOBC  or  NEC  of 
personnel  that  can  be  assigned  to  each  individual  billet,  the 
actual  structure  of  each  reserve  unit  and  which  individuals 
are  actually  assigned  to  those  units/billets.  Billets  that 
are  designated  to  be  manned  from  30  to  90  days  after  initial 
recall  (M+l  to  M+3  designated  billets)  are  filled  by  IRR, 
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standby  reserves,  fleet  reserves  and  retirees.  These 
assignments  are  managed  by  NRPC.  Immediate  mobilization 
billets  are  managed  by  CNRF  and  manned  by  predominantly  SELRES 
assets.  RUMAS  accepts  billet  input  from  NMDAS,  and  in 
addition  to  producing  unit  reports,  compared  actual 
assignments  against  valid  billets.  The  principle  outputs  of 
RUMAS  assist  OP-095,  NMPC,  CNRF  and  NRPC  in  effective 
management  of  reserve  personnel  to  effectively  support  active 
duty  mobilization  requirements. 

3.  Inactive  Remote  Inquiry  System  (IRIS) 

IRIS  is  a  pseudo  real-time  update  capability  that 
provides  data  from  the  Inactive  Officer  and  Inactive  Enlisted 
Master  files.  It  allows  limited  update  capabilities  for 
specific  data  elements.  Most  updates  apply  to  Pretrained 
Individual  Mobilization  Manpower  assets  (PIMMs),  the  NRPC 
managed  personnel  pool.  The  system  is  processed  on  EPMAC 
hardware  in  New  Orleans,  LA  and  accepts  hand-keyed  transaction 
entered  through  NRPC,  NFC  and  NMPC  terminals.  Data  tapes  are 
generated  from  the  updates  and  are  used  during  the  next 
periodic  IMAPMIS  process  to  update  master  files. 

4.  Navy  Enlisted  and  Officer  Retirement  Point  Recording 
System  (NEOPS) 

The  system  that  captures  and  accumulates  Naval 
Reservist  credit  accrued  for  completion  of  drills,  ACDUTRA , 
active  duty  and  completion  of  Correspondence  Courses  is  called 
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NEOPS.  The  recording  and  update  of  these  points  are  essential 
to  reservists.  Members  of  the  Inactive  Naval  Reserve  must 
accrue  adequate  points  for  each  anniversary  year  they 
participate  in  the  reserves  in  order  to  obtain  credit  for  a 
"good  year".  In  order  to  satisfy  the  requirements  for  a 
Certification  of  Eligibility  for  retirement  and  authorization 
for  retirement  pay,  a  reservist  must  have  completed  20  years 
of  satisfactory  service.  The  points  are  accrued  from  active 
duty  participation,  drill  participation,  fulfillment  of  annual 
ACDUTRA  requirements,  and  completion  of  navy  training  courses. 

5.  Inactive  Officer  Promotion  Administrative  System 
( IOPAS ) 

IOPAS  is  operated  and  updated  by  NMPC-93C,  Reserve 
Officer  Promotions,  and  provides  up-to-date  promotional 
history  of  officers  in  the  Naval  Reserve.  IOPAS  provides  the 
capability  to  update  officer  status,  such  as  changes  from 
active  to  inactive  service  and  maintains  the  inactive  officer 
precedence  order.  In  addition,  it  provides  lists  used  to 
determine  eligibility  zones  for  promotion  boards  and  is  used 
to  generate  ALNAV  messages  indicating  promotion  selections. 
The  IOPAS  subsystem  also  has  on-line  terminals  from  which  the 
transaction  updates  produce  another  data  tape. 
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6 .  Pretrained  Individual  Manpower  Management  System 
(PIMMS) 

Updates  pertaining  to  Inactive  Naval  Reservists 
managed  by  NRPC  use  the  PIMMS  subsystem.  PIMMS  is  essentially 
independent  of  IMAPMIS  even  though  the  inputs  are  keyed  by 
NRPC  personnel  and  the  transaction  data  tapes  are  merged  into 
IMAPMIS  master  files  during  processing.  It  is  primarily  used 
for  career  counseling  and  individual  support  of  NRPC  personnel 
assets  and  pertains  mostly  to  non-SELRES  applications.  The 
on-line  data  is  provided  from  extracts  of  the  IRIS  subsystem. 

7.  Inactive  Officer  Master  File  (IOMF) 

The  IOMF  mirrors  the  active  duty  Officer  Master  File. 
It  acts  as  the  central  repository  of  all  Inactive  Naval 
Reserve  officer  personnel  data.  Data  may  be  entered  into  the 
IOMF  from  keyed  input  at  NRPC  or  from  many  data  exchange  tapes 
processed  in  bi-monthly  runs. 

8.  Inactive  Enlisted  Master  File  (IEMF) 

A  complement  of  the  active  duty  Navy  Enlisted  System 
(NES),  the  IEMF  stores  all  data  pertaining  to  Inactive  Naval 
Reserve  enlisted  members.  It  is  similar  to  the  IOMF. 

D.  IMAPMIS  INPUTS,  OUTPUTS  AND  INTERFACES 

1 .  Inputs 

Data  is  input  into  IMAPMIS  at  many  different  sources 
in  many  different  ways.  Some  of  these  sources  have  on-line. 
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real-time  update  capability  while  others  are  recorded  on  tape 
for  future  update  processing.  Among  the  major  sources  of  data 
input  are  the  Reserve  Field  Reporting  System  (RESFIRST),  the 
Reserve  Training  Support  System  (RTSS),  and  several  active 
duty  automated  information  systems  including  the  OMF,  NES  and 
SOS. 

The  data  collected  from  the  individual  NRAs  was,  until 
mid-1989  submitted  entirely  through  the  RESFIRST  system.  All 
personnel  data  involving  reserve  members  was  typed  on  OCR 
scannable  forms  and  submitted  by  mail  to  NRPC.  Even  the  drill 
chits  that  indicated  participation  in  monthly  training  were 
processed  on  special  forms  that  were  mailed  directly  to  NRPC 
where  they  were  scanned.  Data  tapes  were  generated  with  this 
drill  information  and  updates  including  unit  assignments, 
advancements  and  status  changes.  If  the  document  could  not 
be  scanned  due  to  errors,  it  was  returned  to  the  NRA  for 
correction.  If  the  document  was  scannable,  but  the  entries 
were  not  correct,  the  errors  were  not  detectable  until  the 
next  scheduled  processing  run.  This  enormous  paper  system, 
designed  around  the  old  diary  entry  process  was  time  consum¬ 
ing  and  often  documents  were  lost  or  damaged.  Additionally, 
many  errors  were  not  discovered  for  weeks.  Once  the  system 
was  updated  some  errors  were  detected  and  filtered  through  the 
system,  eventually  reaching  the  NRA  for  correction.  However, 
the  most  frequent  means  by  which  NRAs  were  apprised  of  errors 
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resulted  when  the  reserve  member  received  a  check  for  an 
incorrect  amount  of  pay,  or  did  not  receive  a  check  at  all. 

As  recently  as  April  1989,  CNRF  has  brought  the 
Reserve  Standard  Training,  Administrative  and  Readiness 
Support  System  (RSTARS)  on  line.  This  system  which  feeds  data 
to  RTSS  has  decentralized  data  processing  and  centralized 
control.  It  is  designed  for  modular  applications  development 
uses  the  microcomputers  at  the  individual  NRAs  for  the  input 
of  reserve  data.  The  data  structures,  definitions  and 
interfaces  and  edit  checks  to  conform  to  interface  agreements 
formulated  with  IMAPMIS  program  managers.  RSTARS  allows  for 
localized  data  inputs  rather  than  requiring  submission  of  OCR 
paper  documents  for  future  scanning.  The  personnelmen  at  the 
drill/training  sites  can  now  physically  key  in  the  data 
updates.  Those  who  use  and  understand  the  data  now  have  the 
capability  to  enter  the  data.  Daily  data  updates  are  then 
transferred  electronically  via  modem  to  the  CNRF  mainframe  on 
a  nightly  basis.  In  addition  to  the  built-in  standard  data 
entry  edits,  the  CNRF  processing  also  validated  codes  and  data 
elements.  Transaction  errors  were  captured  and  a  complete 
update  of  rejections  was  transmitted  to  the  originating  NRA 
during  the  next  nightly  communication.  From  the  data  updates, 
CNRF's  RTSS  system  produces  bi-monthly  tapes  that  are  to 
submitted  to  NRPC  for  IMAPMIS  update  processing.  The  data  is 
bulk  data  transferred  to  the  PAYPERS  system  for  processing 
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with  IMAPMIS.  This  new  automated  system  improved  the 
timeliness  of  data  and  reduced  the  delays  inherent  to  the 
RESFIRST  mail-in  system.  It  is  anticipated  that  by  the  end 
of  1990  all  RESFIRST  entries  to  IMAPMIS  will  be  input  through 
RSTARS  and  RTSS. 

This  source  of  data  generates  a  high  volume  of 
transactions,  anywhere  between  35,000  to  over  300,000 
transactions  per  month.  RESFIRST  was  originally  scheduled  for 
replacement  by  a  Reserve  module  of  Source  Data  System  (SDS) 
that  would  eliminate  the  need  for  OCR  diary  submissions. 
However,  within  the  last  two  years,  the  development  of 
Reserve  SDS  was  cancelled.  To  compensate  for  this  setback, 
RESFIRST  is  instead  being  replaced  by  a  CNRF  developed  RSTARS, 
which  was  designed  around  pre-negotiated  SDS  interfaces  and 
data  definitions. 

2 .  Outputs 

System  output  reports  is  the  largest  single  product  of 
IMAPMIS.  Currently,  data  from  IMAPMIS  is  output  in  an  almost 
countless  number  of  periodic  reports  that  are  submitted  to 
OPNAV ,  NMPC,  NRPC ,  Director  of  Naval  Reserve,  CNRF  and  the 
NRA.  The  major  areas  of  reporting  are  personnel  support, 
participation  support,  unit  structuring  support, 
administrative  support  and  mobilization  support.  IMAPMIS 
creates  approximately  350  tapes  per  month  to  support  the 
report  function  and  the  redesign  effort  did  not  include  a 
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requirement  to  replace  these  processes,  since  these  reports 
are  very  structured  and  many  are  obsolete,  one  of  the  major 
requirements  of  the  current  phase  of  the  IMAPMIS  redesign  is 
to  totally  review  and  update  all  outputs. 

The  validity  of  many  of  these  reports  in  their  present 
form  is  understandably  being  questioned.  Some  reports  and 
outputs  have  been  determined  as  useless  and  are  no  longer 
being  produced.  Reserve  Unit  Assigned  Documents  ( RUADs ) , 
produced  on  a  monthly  basis,  should  reflect  accurate  timely 
unit  structure  data.  Many  now  reflect  totally  erroneous  data. 
In  one  instance  where  multiple  units  and  their  related  billets 
were  examined,  only  one  single  billet  reflected  the  correct 
rank  and  rates.  (CNRF  letter, 7  November  1989)  The 
significance  of  the  data  outputs  is  that  IMAPMIS  is  the 
corporate  source,  under  the  auspices  of  NMPC  and  NRPC  for  all 
data  relating  to  the  Inactive  Naval  Reserve.  The  data 
collected  and  output  by  IMAPMIS  is  a  direct  reflection  on  the 
training,  manning  and  readiness  levels  of  the  naval  reserve. 
If  the  data  is  not  credible,  then  the  reports  are  also 
invalid.  Memaging  a  system  as  large  as  IMAPMIS  is  difficult 
at  best.  However,  the  quality  of  the  naval  reserve  database 
is  severely  inadequate  and  reflects  poorly  on  the  dedicated 
individuals  who  participate. 
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3.  interfaces 


As  can  be  deduced  from  the  previous  pages,  IMAPMIS  is 
linked  in  one  form  or  another  to  numerous  internal  and 
external  systems.  To  be  able  to  accurately  transfer  data 
among  these  various  systems  requires  adequate  interfaces  that 
edit  and  validate  incoming  data,  without  tightly  restricting 
data  passage.  This  is  a  difficult  division  to  make. 
Historically  IMAPMIS  has  required  inordinately  tight  edits  on 
data  for  reasons  that  were  applicable  when  the  system  was 
initially  designed.  However,  many  of  these  edits  are  no 
longer  valid  in  today's  environment  (CDR  R.  Rautenberg, 
October  1989).  Since  the  conversion  of  IMAPMIS  to  a  database 
did  not  attempt  to  redesign  the  processes  or  requirements, 
many  of  these  old  requirements  are  still  in  place  and 
functioning  and  have  disruptive  effects  on  all  concerned. 
Currently  all  data  is  still  comprehensively  edited  whether  it 
is  received  from  another  automated  system  or  input  through 
CRT's.  The  data  is  checked  for  completeness,  proper  coding 
and  data  relationships.  Other  data  is  validated  using 
reference  tables,  logic  examinations  and  comparison  to 
personal  data  already  existing  in  the  system.  These  edits 
were  designed  for  the  RESFIRST  system  rather  than  new 
relational  database.  The  problem  lies  herein.  If  the  data 
already  contained  in  the  IMAPMIS  database  is  incorrect,  then 
the  edit  checks  will  not  allow  the  update  of  some  data 
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elements.  The  problems  that  these  interface  constraints 
create  is  enormous.  As  previously  mentioned,  many  data  tape 
updates  are  not  processed  into  master  file  updates  on  a  real 
time  basis.  For  the  internal  subsystems  of  IMAPMIS,  a  data 
element  may  have  been  corrected  and  a  transaction  generated 
on  the  data  update  tape  only  to  find  that  weeks  later  when  the 
tape  is  processed,  the  transaction  may  be  rejected  by  an 
interface  edit.  An  example  of  the  complex  sample  data  flows 
from  the  NRA  to  the  generation  of  a  SELRES  paycheck  is  shown 
in  Figure  4. 

Another  of  the  major  external  systems  with  which 
IMAPMIS  must  interface  is  the  Reserve  Component  Common 
Personnel  Data  System  (RCCPDS),  managed  by  the  Defense 
Manpower  Data  Center  (DMDC)  in  Monterey,  CA.  RCCPDS,  a  DOD 
system  that  collects  Reserve  personnel  data  from  all  DOD 
systems . 

Through  the  use  of  IMAPMIS,  the  Naval  Reserve  Personnel 
Center  (NRPC)  is  tasked  with  maintaining  current  files  on  all 
750,000  Inactive  Naval  Reserve  personnel.  To  accomplish  this 
task,  IMAPMIS  must  interface  with  many  external  systems. 
These  systems,  belonging  to  other  commands  may  simply  accept 
data  from  IMAPMIS,  pass  data  to  IMAPMIS,  or  process  available 
data.  Systems  that  process  data  may  or  may  not  return  updated 
data  to  IMAPMIS.  Among  the  systems  with  which  IMAPMIS  must 
maintain  workable  interfaces  are  the  Navy  Manpower  Data 
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Figure  4.  SELRES  Pay  Data  Flows 
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Accounting  System  (NMD AS)  to  access  mobilization  billet 
requirements;  all  active  duty  personnel  systems  such  as  the 
Officer  Master  File  (OMF)  and  the  Enlisted  Master  File  (EMF) ; 
the  Navy  Pay  Personnel  System  (PAYPERS)  hardware  and  software 
for  processing  drill  and  ACDUTRA  pay;  and  DOD  Reserve 
Component  Common  Personnel  Data  System  (RCCPDS)  to  provide 
periodic  and  ad  hoc  reports.  The  quality  of  each  of  these 
interfaces  is  critical  in  their  own  way.  CNRF  and  OP-095, 
responsible  for  training  and  readiness  of  SELRES  require 
valid,  accurate,  up-to-date  data  on  the  status  of  the  reserve 
community.  The  SELRES,  who  depend  on  accurate  personnel  data 
to  ensure  proper  remuneration  for  reserve  participation 
deserve  the  same  accurate,  timely  transfer  and  update  of  data. 
NRPC ,  tasked  with  what  seems  an  unmanageable  responsibility 
must  coordinate  and  administer  a  system  that  reports,  accepts 
and  processes  data  from  many  internal  and  external  sources. 


E.  SHORTFALLS  AND  INADEQUACIES  OF  IMAPMIS 

The  Deficiency  Statement  contained  in  the  initial  System 

Decision  Paper  initiating  the  redesign  of  IMAPMIS  stated: 

Valid,  accurate  and  current  information  as  well  as 
financial  data  is  not  being  provided  to  Selected  Reserve 
Headquarters  and  field  commands,  or  to  many  echelons  of 
DON  and  DOD  managers.  We  are  not  using  an  effective  or 
efficient  methods  of  transferring  data  between  Active  and 
Inactive  files;  mobilization  pre-assignments  as  well  as 
assignments  at  Mob-Day  must  be  made  manually  and  therefore 
cannot  meet  mobilization  requirements;  the  NMDAS/RUMAS 
interfaces  are  totally  inadequate  and  present  numerous 
problems  to  OP-09R  (now  OP-095],  CNAVRES  and  Reserve  Field 
Commands  with  regard  to  incorrect  manpower  authorization 
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documents;  and  IMAPMIS  data  elements  often  do  not  match 
nor  can  be  directly  translated  to  those  required  by  DOD 
and  other  users.  Therefore,  the  Naval  Reserve  Personnel 
Center  is  not  adequately  performing  its  mission  of 
providing  personnel  information  support  to  its  many  users. 
Because  of  the  age  and  migration  history  of  the  source 
code  of  IMAPMIS  and  the  lack  of  documentation  thereof, 
minor  design  changes  to  the  system  are  attempted  only  in 
rare  and  emergency  situations.  (IMAPMIS  SDP  1,1983) 

For  the  redesign  of  IMAPMIS,  four  alternatives  were 
considered.  The  first  was  to  continue  with  the  status  quo  and 
not  change  IMAPMIS.  The  second  alternative  proposed  a  single 
interactive  project  to  incorporate  all  required  improvements 
to  IMAPMIS.  The  third  alternative,  similar  to  the  second, 
used  a  two-phase  approach  to  improve  IMAPMIS.  The  first  phase 
would  concentrate  on  redesigning  the  IOMF  and  IEMF  and  the 
operation  to  maintain  them.  The  second  phase  would  then  build 
on  the  first  phase  and  eventually  improve  the  entire  system. 
The  final  alternative  was  a  three-phased  proposal  to  first 
update  the  IOMF  and  IEMF,  then  modify  output  and  report 
generations  and  add  an  ad  hoc  query  capability  and  finally, 
the  last  phase  would  improve  the  interfaces  between  IMAPMIS 
and  other  external  systems.  The  ultimate  decision  was  to 
select  the  fourth  alternative.  During  the  initial  planning 
phase,  it  was  decided  to  concentrate  on  converting  the 
existing  flat  file,  sequential  batch  system  into  a  relational 
database.  The  conversion  which  began  in  1981  did  not  include 
any  significant  functional  enhancements,  allow  development  of 
the  proposed  ad  hoc  query  capability,  improve  any  of  the 
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output/reporting  formats,  or  improve  any  of  the  external  and 
internal  interfaces  of  IMAPMIS.  With  the  new  database  being 
placed  on-line  and  functioning  in  April  1989,  the  system  is 
somewhat  faster  than  the  old  version  and  some  basic  inquiries 
are  more  efficient.  However,  the  inadequacies  of  the 
interfaces  and  the  inability  of  IMAPMIS  to  provide  OP-095  and 
CNRF  with  up-to-date,  accurate  information  regarding  Selected 
Reserves  still  exist.  The  first  of  the  three  phases  took  two 
years  longer  than  the  originally  projected  life  cycle.  Al¬ 
though  new  enhancements  to  IMAPMIS  are  being  considered  under 
phase  two  to  improve  these  functions,  other  factors  are 
draining  resources.  In  an  environment  where  data  access, 
processing  and  utilization  is  paramount,  government  officials 
demand  up  to  date  information  when  making  crucial  decisions 
involving  the  Armed  Forces.  As  the  repository  for  all  Naval 
Reserve  personnel  information,  being  able  to  provide  accurate 
and  timely  data  is  rapidly  becoming  a  major  concern  and 
priority  for  IMAPMIS  managers  and  system  planners. 

Although  improvements  are  essential,  NRPC  is 
responsible  for  providing  information  on  all  Naval  Reserves. 
Selected  Reservists  comprise  approximately  131,000  of  the 
750,000  records  maintained  by  NRPC.  However,  this  relatively 
small  percentage  of  records  generates  a  large  percentage  of 


NRPC  workload. 


It  is  important  to  recall  the  importance  of  the  SELRES 
who  comprise  the  backbone  of  the  Naval  Reserve.  They 
represent  the  best  trained,  immediately  mobilizable  assets 
available  to  the  Navy.  Taking  into  account  the  multitude  of 
conflicting  priorities  and  pressures  on  NRPC,  it  is  still 
necessary  to  remember  that  SELRES  are  vital  resources  and 
their  needs  must  be  addressed.  Nothing  more  seriously  affects 
SELRES  retention,  training  levels  and  morale  than  the 
continued  loss  of  or  incorrect  pay. 

1.  Mobilization  Billet  Structuring  Problems 

As  discussed  earlier  in  the  chapter,  updated 
mobilization  billet  requirements,  reported  through  NMDAS,  are 
essential  to  CNRF.  Responsible  for  effective  training  of 
SELRES,  CNRF's  function  is  to  structure  these  billets  into 
individual  reserve  units  at  NRAs  throughout  the  United  States. 
The  billets  were  passed  through  IMAPMIS  to  CNRF  where  they 
were  manually  manipulated  into  units.  Without  any  computer 
aided  support,  it  was  a  slow  difficult  process  that  usually 
did  not  yield  the  optimum  unit  structures.  However,  the  CNRF 
computer  department  concurrently  designed  a  limited  decision 
support  system  (DSS)  for  helping  the  structuring  process  and 
is  in  the  process  of  developing  this  application.  After  many 
years  of  discussion  CNRF  was  finally  authorized  a  direct 
interface  with  NMDAS  to  obtain  the  billet  data  through  RTSS 
rather  than  passing  data  through  IMAPMIS  and  waiting  on 
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scheduled  processing.  This  improvement,  which  is  approved  for 
June  1990  implementation  will  significantly  improve  the 
timeliness  of  data  received  by  CNRF  and  with  the  DSS  should 
prove  to  enhance  overall  unit  structuring  efforts.  However, 
problems  still  exist  in  IMAPMIS  where  units  that  have  been 
dissolved  are  still  carried  in  the  database.  This  happens 
because  IMAPMIS  defaults  will  not  allow  deletion  of  a  unit 
until  all  assigned  personnel  are  transferred  out  of  the  unit. 
If  the  individual  transfer  transaction  is  not  accepted  by 
IMAPMIS,  the  member  will  remain  assigned  to  the  unit  and  the 
unit  will  continue  to  be  reflected  long  after  being 
disestablished . 

2.  Interface  Problems 

The  IMAPMIS  interfaces  as  they  exist  today  are  totally 
inadequate  to  support  the  day  to  day  data  requirements  of 
NRPC.  A  good  illustration  of  interface  problems  involves  an 
active  duty  member  being  released  and  transferred  to  the  Naval 
Reserve.  Although  NES  and  SDS  are  updated  to  reflect  the  loss 
of  the  member  and  release  orders  are  generated,  IMAPMIS  and 
NRPC  are  completely  unaware  of  the  pending  gain  to  the  Naval 
Reserve  until  the  point  in  time  that  the  individual's  service 
record  physically  arrives  in  the  NRPC  mail  room.  Since 
IMAPMIS  theoretically  interfaces  with  NES  and  SDS,  this  data 
and  the  individual's  service  record  information  should  be 
automatically  transferred  and  a  flag  should  be  generated  for 
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NRPC  to  expect  the  service  record.  In  actuality,  when  the 
record  is  received  at  NRPC,  it  is  screened  manually  for 
pertinent  data  items  including  a  Reserve  contract  commitment 
and  the  member's  current  address.  Exacerbating  the 
frustration,  the  data,  up  to  19  fields,  is  hand-scribed  onto 
a  data  input  form  that  is  later  given  to  an  operator  who 
physically  hand-keys  the  data  into  IMAPMIS.  This  initial 
input  actually  establishes  the  individual  as  a  member  of  the 
Naval  Reserve  community.  Without  this  data  entry,  the 
individual  will  not  be  reflected  in  the  main  IMAPMIS  database 
regardless  of  his  status  in  NES  and  SDS,  and  he/she  cannot 
affiliate  with  a  Reserve  unit,  participate  in  any  reserve 
functions  or  receive  any  pay.  The  problem  is  further 
compounded  when  an  individual  is  released  from  active  duty 
and  subsequently  reports  to  the  closest  reserve  activity  to 
affiliate  with  a  unit.  The  proper  diary  entries  are  made  and 
submitted,  but  will  be  automatically  rejected  several  weeks 
later  when  the  system  is  updated  since  there  is  no  record  of 
the  individual  in  the  database.  Interestingly  enough,  the 
active  duty  Officer  Master  File  (OMF)  and  Enlisted  Master  File 
(EMF)  were  designed  and  completed  by  different  contractors. 
Subsequently,  the  interfaces  between  these  two  systems  and 
IMAPMIS  are  totally  different.  For  officers,  as  an  example, 
IMAPMIS  does  receive  indications  of  losses  from  active  duty 
and  pending  gains.  However,  similar  types  of  data  must  be 
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hand-keyed  into  IMAPMIS  after  a  physical  screen  of  the 
officer's  record.  During  a  recent  visit  to  NRPC,  it  was  noted 
that  operators  were  using  Officer  Data  Cards  (ODCs)  generated 
by  NMPC  to  input  officer  Naval  Occupational  Billet  Codes 
( NOBCs )  and  Additional  Qualification  Designators  ( AQDs ) . 

In  addition  to  RESFIRST  diary  entry  inputs,  IMAPMIS 
now  allows  a  bi-monthly  update  from  CNRF  RTSS  system.  The 
RTSS  system  is  updated  daily  from  a  majority  of  the  NRAs ,  thus 
maintaining  a  reasonably  current,  accurate  database.  Limited 
edit  checks  are  built  into  the  initial  data  capture  at  the 
activities,  however,  extensive  edits  are  performed  on  uploaded 
data  to  ensure  validity.  When  these  checks  reject  data  or 
inputs,  the  submitting  reserve  activity  is  aware  of  the 
problem  the  following  working  day.  ( Schwartz , October 
1989, p. 49)  However,  problems  have  surfaced  with  the  interface 
with  IMAPMIS.  The  RTSS  database,  a  valid,  accurate  database 
is  uploaded  daily.  Conversely,  IMAPMIS  is  updated  during  bi¬ 
monthly  processing  runs  and  lags  significantly  behind  RTSS. 
Within  IMAPMIS  there  are  numerous  duplications  of  edit  checks 
already  performed  in  RTSS  and  additional  edit  checks  that  have 
little  relevance  on  the  data  input.  These  edits  routinely 
reject  and  override  otherwise  valid  transactions  obtained 
directly  from  the  SELRES  and  input  at  the  NRAs.  These 
interface  problems  were  specifically  addressed  by  CNRF  in 
correspondence  to  NR PC  explicitly  stating  their  frustrations 
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in  attempting  to  analyze  rejected  transactions  created  in  the 
interface  of  IMAPMIS  and  RTSS.  The  letter  indicated  that  NRPC 
was  not  providing  satisfactory  support  in  attempting  to 
identifying  why  transactions  were  being  rejected  from  IMAPMIS. 
The  CNRF  perspective  focused  on  the  fact  that  there  seemed  "to 
be  no  effort  to  analyze  refections  to  ensure  they  should  in 
fact,  be  rejected."  (CNRF  letter , November  1989).  In  addition 
to  data  quality  and  SELRES  pay  problems,  this  perceived  lack 
of  responsiveness  on  the  part  of  NRPC  further  strained  the 
relationship  between  CNRF  and  NRPC.  However,  with  the 
enormous  workload  at  NRPC,  the  response  is  more  likely 
attributable  to  trying  to  support  too  many  priorities  with 
sadly  inadequate  resources. 

3 .  Design  Problems 

Still  another  problem  within  IMAPMIS  involves  the  flat 
file  mentality  of  the  RESFIRST  diary  entry  system.  The  diary 
entry  was  developed  to  provide  numerous  pieces  of  data 
collectively  in  a  prescribed  order  and  format  for  efficient 
update.  Since  the  system  was  designed  for  batch,  sequential 
processing,  all  data  items  had  to  be  updated  on  a  single  pass, 
thus  requiring  that  multiple  data  entries,  in  predefined 
formats.  The  entry  was  submitted  on  special  forms  typed  in 
OCR  fonts,  and  mailed  in  special  envelopes  to  NRPC.  There, 
the  forms  were  hand-fed  into  optical  scanners  and  data  tapes 
were  produced  for  later  merging  with  the  IMAPMIS  database. 
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Few  errors  were  detected  upon  scanning  and  most  remained  on 
the  tape  unidentified  until  processing,  weeks  later. 

Within  the  RESFIRST  diary  input  system,  there  were 
many  transactions  that  were  a  series  of  entries  "bundled" 
together.  Multiple  entries  were  required  for  a  single 
personnel  status  change.  A  good  example  is  a  simple 
advancement.  The  change  in  status  required  two  separate  diary 
entries:  the  first  for  discharge  of  the  member  and  is  followed 
by  an  advancement  entry.  If  these  entries  are  in  the  wrong 
sequence  or  the  discharge  entry  is  omitted  or  erroneous,  the 
advancement  will  not  be  recorded  and  the  member  will  only  be 
paid  at  the  previous  rate.  Similarly,  if  an  individual  is 
transferred  from  one  unit  to  another,  an  entry  must  first 
appear  to  show  the  individual  as  a  loss  to  the  original  unit. 
This  must  then  be  followed  by  an  entry  for  a  personnel  gain 
to  the  ultimate  unit.  Again,  before  the  member  can  be 
properly  assigned  to  the  new  unit,  both  of  these  entries  must 
be  made  in  the  proper  order.  The  normal  sequence  of  events 
is  such  that  the  individual  reports  to  the  new  unit  the 
following  drill  period  and  a  drill  chit  is  processed  and 
submitted.  However,  IMAPMIS  still  holds  the  member  in  the  old 
unit.  Not  only  is  the  drill  chit  rejected,  disallowing  the 
member's  pay  and  participation  credit,  it  also  reflects  that 
the  member  has  missed  a  drill  period  at  his  authorized  unit. 
Numerous  other  examples  exist  of  these  "bundled"  transactions. 
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They  all  create  major  problems  for  the  SELRES  members  and  the 
NRA  staffs  that  support  them.  Such  problems  as  these  tend  to 
generate  even  more  problems  and  inaccurate  data  throughout 
IMAPMIS.  For  example,  a  billet  at  the  new  unit  is  still 
unfilled  according  to  IMAPMIS  and  it  is  possible  that  another 
member  may  be  assigned.  Conversely  filled,  the  billet  is 
shown  as  being  vacant  and  detracts  from  the  manning,  readiness 
and  training  status  of  the  unit.  The  individual  is  not 
receiving  credit  or  pay  for  participation.  Such  problems  may 
take  anywhere  from  45  to  90  days  to  correct.  It  is  obvious 
that  problems  of  this  kind  have  a  major  waterfall  effect  and 
result  in  incorrect  information  concerning  manning  and 
training  levels  of  SELRES. 

4.  Parallel  Processing  Problems 

Expanding  on  the  frustrations  encountered  with 
problems  of  "bundled"  transactions,  another  significant 
processing  problem  was  discovered  after  the  database 
conversion  was  completed.  It  was  noted  that  many  of  these 
"bundled"  transactions  w  e  being  totally  rejected  from 
IMAPMIS  processing  runs.  Only  after  months  of  research  was 
it  discovered  that,  by  implementing  a  parallel  processing 
capability  to  run  IMAPMIS,  the  second  or  new  data  entry  was 
often  processed  before  the  initial  entry.  Therefore,  the 
system  attempted  to  process  the  second  entry  before  the  first. 
This  resulted  in  this  specific  transaction  being  rejected. 
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Subsequently,  when  the  first  transaction  was  processed,  there 
was  no  second  transaction  to  update  the  first.  As  can  be 
imagined,  the  results  were  disastrous.  Examples  included 
advancement  transactions  where  the  individual  advancement  was 
processed  before  the  discharge  transaction.  These 
transactions  were  immediately  rejected  due  to  the  lack  of  a 
discharge  entry.  Next,  when  the  discharge  transaction  ran, 
the  individual  was  automatically  discharged.  Since  the 
advancement  transaction  had  already  been  rejected,  the 
individual  was  then  reflected  in  IMAPMIS  as  being  discharged. 
Here  again,  the  individual  could  not  receive  pay  for  drill  or 
participation  credit  until  the  master  database  was  updated. 
Support  staff  at  the  NBAs  continued  submitting  the  same 
entries,  but  were  unable  to  correct  the  member's  status.  The 
resolution  of  this  single  problem  took  in  excess  of  three 
months  to  identify  and  many  instances  still  remain  unresolved. 
Meanwhile  unit  strength  codes  were  incorrect  and  members  were 
not  being  properly  paid. 

5.  Strength  Code  Problems 

Within  RESFIRST,  SELRES  are  assigned  strength  codes  to 
indicate  the  location  of  their  service  record  and  drill  site. 
Since  SELRES  move  frequently  without  transfer  orders  like 
active  duty  personnel,  a  system  of  tracking  the  member  and 
his/her  respective  service  record  was  essential.  To  do  this, 
strength  codes  were  devised.  If  the  member  and  service  record 
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were  held  by  the  same  NRA,  the  strength  code  was  valid  and 
allows  processing  of  personnel  status  updates.  If  the  record 
and  individual  were  not  held  by  the  same  NRA,  the  strength 
code  prevented  many  personnel  data  updates.  If  for  some 
reason,  a  SELRES  is  not  properly  assigned  to  a  unit,  it 
affects  an  assigned  strength  code.  If  this  strength  code  is 
not  the  proper  value,  the  individual  is  not  allowed,  according 
to  RESFIRST  Manual,  to  be  transferred,  be  promoted,  discharged 
or  physically  die. 

6.  Audit  Trail  Problems 

Actually  affecting  all  of  the  previously  discussed 

problems,  another  significant  shortcoming  of  IMAPMIS  is  the 

lack  of  any  audit  trail  for  transactions .  In  the  previous 

cases  cited,  there  was  no  way  to  quickly  identify  problem 

trends.  Once  the  transaction  was  rejected,  it  was  gone.  This 

lack  of  functionality  makes  it  exceptionally  difficult  to 

troubleshoot  or  review  for  problem  trends.  A  proposed 

solution  would  be  to  accept  a  single  entry  that  would  then 

generate  the  required  data  for  both  the  first  and  second 

entries.  Audit  routines  should  be  embedded  into  IMAPMIS. 

Most  system  users  are  aware  that: 

The  edit-validation-update-re j  ect-correction-reentry 
process  is  considered  critical. . .because  it  determines, 
to  a  great  extent,  the  reliability  of  a  systems's  output. 
Unless  handled  properly,  rejected  transaction  may  be  lost 
entirely  or  never  corrected.  (Benoit, May  1979, p. 26) 
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Within  IMAPMIS  there  is  no  provision  for  suspense  files, 
automated  error  files  or  even  minimal  error  messages.  Since 
this  single  problem  contributes  heavily  to  others  documented 
above,  it  should  be  a  high  level  priority  for  future 
enhancements  to  IMAPMIS. 

F.  IMPACT  OF  IMAPMIS  SYSTEM  SHORTFALLS 

As  is  illustrated  in  these  few  examples,  IMAPMIS  is  a 
large,  unwieldy  system,  designed  around  old  hardware 
technology  and  concepts  such  as  diary  entries.  IMAPMIS  is 
inflexible,  slow  and  unresponsive  to  the  needs  of  today's 
SELRES.  The  problems  enumerated  above  are  primarily  related 
to  SELRES  and  represent  only  a  few  of  an  overwhelming  number 
of  enhancements  that  are  required  in  IMAPMIS.  System 
interfaces  affect  every  reserve  category  and  have  serious 
effects  on  the  quality  of  data  reported  to  external  systems 
such  as  RCCPDS.  These  erroneous  reports  generated  from  poor 
quality  data  do  not  accurately  reflect  manning  levels, 
training  and  readiness  status  and  overall  condition  of  the 
Naval  Reserve  Force.  The  problems  associated  with  "bundled" 
transactions  must  be  evaluated  and  realistic  database 
management  solutions  applied.  The  entire  design  of  IMAPMIS 
should  be  evaluated  to  more  clearly  identify  individual 
command  responsibilities  and  data  ownership.  Similarly,  the 
possibility  of  segmenting  IMAPMIS  into  several  modular 
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processes  divided  among  the  responsible  commands  may  provide 
some  solutions.  Only  after  specific  responsibilities  are 
agreed  upon  and  inter-organizational  issues  are  identified  and 
resolved,  can  we  expect  to  improve  the  quality  of  the  IMAPMIS 
data  and  processes. 

As  has  been  repeatedly  observed,  IMAPMIS  is  an  unreliable, 
cumbersome  and  generally  unsatisfactory  conglomeration  of 
programs  and  systems.  Data  and  information,  frequently 
reported  incorrectly,  are  used  by  managers  of  the  Naval 
Reserve  and  external  organizations  to  evaluate  the  status  of 
the  force  and  to  determine  future  directions  and  policies. 
Moreover,  the  applications  do  not  lend  themselves  to 
modification  or  enhancement  and  more  they  do  not  support  the 
requirements  of  either  CNRF  or  NRPC. 

IMAPMIS,  a  result  of  automating  manual  processes  and  data 
collection,  was  not  intended  to  and,  in  its  present  form, 
cannot  provide  the  managerial  support  required  by  either  NRPC 
or  CNRF. 

In  spite  of  these  inadequacies,  IMAPMIS  is  still  the 
official  repository  of  data  concerning  the  Inactive  Naval 
Reserve.  The  objectives  of  IMAPMIS  redesign,  as  formulated 
in  the  early  1980s  and  listed  below,  were  to  correct  these 
very  problems.  IMAPMIS  redesign  was  intended  to: 
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1.  Support  inactive  reserve  information  requirements  with 
valid,  accurate  and  timely  manpower  information 

2.  Provide  personnel  and  authorization  data  for  screening 
and  assigning  personnel  for  mobilization 

3.  Provide  an  automated  assist  in  structuring  billet 
authorizations  into  reserve  units 

4.  Respond  to  mobilization  requirements  promptly 

5.  Record  officer  and  enlisted  reserve  participation  data 

6.  Provide  effective  and  efficient  exchange  of  data 
between  active  and  inactive  personnel  files 

7 .  Provide  personnel  data  for  inactive  reserve  member 
promotion  board  support 

However,  throughout  the  redesign  effort  (1981-1990),  IMAPMIS 
functionality  has  remained  stagnant.  Not  one  goal  of  the  SDP 
I  has  been  achieved,  and  there  has  been  significantly  little 
progress  toward  any  of  the  seven  objectives. 

Projections  for  the  redesign  of  IMAPMIS  estimated  a  total 
life  cycle  of  seven  years  at  a  cost  of  $  21,773,000  and  a 
completion  milestone  for  phase  one  in  March  1985  (IMAPMIS  SDP 
1,1983).  Actual  spending  data  for  phase  I  is  not  available, 
however  figures  for  the  period  of  fiscal  years  1983  through 
1986  reflect  cost  overruns  of  approximately  1,371,000.  After 
nine  years,  two  years  longer  than  the  entire  projected  life 
cycle  of  all  three  phases  of  the  development  effort,  IMAPMIS 
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is  still  a  long  way  from  meeting  the  requirements  specified 
in  1981.  The  project,  as  typical  of  large  systems,  exceeded 
all  cost  projections  and  was  embarrassingly  years  behind 
schedule . 

Considering  the  reduction  in  military  budgets  and  the 
congressional  interest  in  over-budget,  over-schedule  ADP 
system  development  (HOR  Report  101-121, July  1989),  it  is 
highly  doubtful  whether  IMAPMIS  will  ever  be  able  to  meet  all 
of  its  functional  requirements.  Although  the  core  of  IMAPMIS 
has  successfully  been  transformed  into  a  relational  database, 
the  data  itself  is  wrought  with  errors.  The  centralized 
control  policies  and  lack  of  interface  between  IMAPMIS  system 
developers  and  end  users  also  reflect  traditional  batch- 
oriented  management  philosophies  that  have  created  a  virtual 
wall  between  users  in  the  field  and  NRPC. 

Meanwhile,  throughout  the  transition  from  a  flat  file 
system  to  relational  database,  the  functional  requirements, 
including  the  need  for  management  reports  and  ad  hoc  queries 
increased  significantly.  Due  to  the  original  design  and  poor 
documentation  of  IMAPMIS  applications,  they  cannot  be 
modified.  Instead,  each  process  must  be  individually 
examined,  redesigned  and  rewritten  to  meet  the  current 
requirements  within  a  database  environment. 

Within  the  redesign  effort,  the  huge  number  of  new 
processes  needed  to  rectify  these  problems  and  the  extended 
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period  of  time  required  to  develop  them  are  unacceptable. 
While  all  of  the  organizations  that  use  IMAPMIS  are  aware  of 
these  inadequacies,  until  recently,  there  has  been  no 
alternative . 

To  continue  with  the  status  quo  of  IMAPMIS  will  adversely 
affect  all  aspects  of  the  Naval  Reserve,  particularly  OP-095 
and  CNRF  in  their  ability  to  provide  well-trained  SELRES. 
Other  alternatives  should  be  examined  before  more  resources 
are  devoted  to  IMAPMIS.  With  the  present  emphasis  on 
downsizing  ADP  systems  and  future  probabilities  of  austere 
budget  constraints,  it  is  postulated  that  physically  trans¬ 
ferring  the  SELRES  database  maintenance  responsibilities  from 
NRPC  could  provide  a  viable  solution  to  all  concerned.  Since 
RSTARS  and  RTSS  became  operational,  CNRF  now  has  the  technical 
and  managerial  capability  to  not  only  maintain  this  database, 
but  also  the  ability  to  interface  directly  with  other  external 
systems  such  as  NFC's  PAYPERS  and  OPNAV's  NMD AS .  By  removing 
this  responsibility  for  SELRES  data  maintenance  from  NRPC, 
thousands  of  hand  inputs  per  month  could  be  eliminated.  The 
resources  of  NRPC,  being  relieved  of  the  tremendous 
responsibilities  of  maintaining  the  SELRES  database  could  then 
be  diverted  to  other  crucial  problems  involving  the  remaining 
Naval  Reserve  database. 
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III.  ISSUES  CONCERNING  FUTURE  IMPROVEMENTS  TO  IMAPMIS 

In  this  chapter,  management-related  issues  concerning 
information  systems  and  how  they  relate  to  the  problems  and 
shortcomings  of  IMAPMIS  will  be  addressed.  Organizational 
issues,  centralization/decentralization  concerns,  disputes 
over  data  ownership,  problems  of  data  quality  and  control  and 
finally  system  interface  concerns  will  be  discussed.  These 
issues,  each  bearing  significantly  on  the  success  of  both 
NRPC  and  CNRF  as  organizations,  exert  a  direct  influence  on 
the  future  of  IMAPMIS  and  where  SELRES  database 
responsibilities  belong. 

A.  ORGANIZATIONAL  CONCERNS 

The  Installation  of  the  first  commercial  computer  in  1952, 
became  the  beginning  of  a  new  age  of  information  technology 
(IT).  Since  that  time,  IT  has  evolved  rapidly,  with  computer 
hardware  technology  and  processing  capability  improving  at  the 
rate  of  30  to  40  percent  each  year.  Microcomputers  of  the 
late  1980s  surpass  the  processing  capabilities  of  the  IBM  370 
mainframe  series  of  the  early  1970s. 

Today,  with  the  availability  of  vast  amounts  of  data  and 
relatively  low  cost  equipment,  information  is  becoming 
increasingly  important  to  the  success  of  organizations.  Due 
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to  its  expanded  significance,  information  is  widely  being 
considered  a  valuable  strategic  resource.  Its  importance  in 
achieving  organizational  objectives  is  regarded  equally  with 
personnel  and  financial  assets. 

The  goal  of  organizations  today,  and  the  Navy  is  no 
exception,  is  to  use  information  and  information  resources  to 
achieve  the  greatest  possible  gain  in  mission  effectiveness. 
However,  in  order  to  achieve  this  goal,  plans  for  information 
systems  development  and  usage  must  be  aligned  with  strategic 
command  objectives.  Use  of  systems  that  do  not  support  these 
goals  will,  in  all  likelihood,  prove  counterproductive  to  the 
command.  Implementation  of  new  technologies  will  provide 
better  methods  of  accomplishing  mission  needs  only  if  the  long 
range  information  and  data  needs  of  the  command  are  understood 
and  systems  are  developed  accordingly.  The  alternative 
courses  of  action  that  result  from  these  plans  may  lead  to 
changes  in  organizational  structures  and  relationships  in 
order  to  better  realize  advantages  of  new  information 
opportunities  (DOD  (MPT), June  1987, p. 5).  Restated, 
organizations  should: 

...base  decisions  regarding  the  need  for  new  or  improved 
automated  information  systems  on  a  careful  analysis  of  the 
current  organizational  functions  and  the  ways  that 
information  systems  are  currently  supporting  them,  and 
what  is  needed  to  make  the  organization  (as  a  whole)  more 
effective  in  accomplishing  its  goals.  (DCNO  (MPT), July 
1987,p.iii) 
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Designed  to  automate  clerical  functions  and  collect  data, 
IMAPMIS  was  developed  in  support  of  NRPC's  predominantly 
administrative  organizational  mission.  Its  primary  function 
was,  and  is  today,  to  support  an  efficient,  effective 
mobilization  of  reserve  assets  by  maintaining  an  accurate, 
comprehensive  collection  of  information  about  members  of  the 
Inactive  Naval  Reserve. 

However,  many  of  these  reservists,  the  SELRES  fall  under 
the  direct  operational  control  of  CNRF .  The  CNRF  mission  is 
to  structure  mobilization  billets  into  effective  and  efficient 
units  and  subsequently  train  and  administer  SELRES  that  will 
fill  those  billets.  Dependent  on  IMAPMIS  as  his  source 
system,  CNRF  is  vitally  interested  in  the  way  that  IMAPMIS  is 
managed,  its  responsiveness  to  his  mission,  and  how  future 
application  development  decisions  are  made.  Information  is 
of  strategic  importance  and  essential  for  CNRF' s  future 
success  in  a  climate  of  shrinking  budgets  and  increasing 
pressures  for  improved  performance.  Yet,  IMAPMIS  is 
administered  and  controlled  by  an  organization  that  is  not 
only  external  to  CNRF,  but  is  not  even  within  the  chain  of 
command.  CNRF  is  not  receiving  adequate  support  from  IMAPMIS 
and  further,  has  absolutely  no  control  over  decisions 
regarding  the  future  of  IMAPMIS  and  data  critical  to  mission 
accompl i shment . 
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Thus,  two  highly  disparate  organizations  with  entirely 
different  goals,  must  rely  on  a  common  database  and  processing 
system  for  support.  At  some  point  in  the  near  future,  it  must 
be  recognized  that  IMAPMIS  cannot  effectively  support  both  of 
these  incongruous  missions  simultaneously.  Therefore,  each 
command  should  closely  examine  and  redefine  its  own  internal 
information  requirements  and  proceed  with  appropriate  actions 
to  accomplish  them. 

This  reexamination  of  the  future  of  IMAPMIS  and  its 
ability  to  support  both  NRPC  and  CNRF  missions  involves  a 
highly  political  issue  of  control.  To  be  truly  effective,  the 
database  and  associated  applications  should  more  accurately 
reflect  the  attitudes,  policies  and  goals  that  influence  all 
aspects  of  CNRF.  Without  CNRF  being  able  to  exert  any 
influence  over  these  issues,  IMAPMIS  will  continue  to  operate 
independently  of  this  primary  user.  A  recent  study  to  combine 
the  ADP  application  developments  of  both  CNRF  and  NRPC  into 
a  single  echelon  three  command  that  would  act  as  a  centralized 
design  agency  would  finally  allow  input  from  the  CNRF 
perspective  and  should  be  adopted. 

B.  CENTRALIZATION/DECENTRALIZATION  ISSUES 

Historically,  management  of  information  systems  was 
centralized  to  enhance  processing  efficiency  and  enforce 
organizational  policies.  Applications  were  batch-oriented  and 
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not  easily  distributed.  With  the  rapid  expansion  of 
technology  over  the  last  decade,  the  demand  for  information 
increased.  If  users  could  not  get  responsive  results  from  ADP 
departments,  microcomputers  were  obtained  for  local  use, 
circumventing  centralized  systems.  This  also  created  problems 
as  control  of  data  and  policies  was  lost  and  islands  of 
information  developed.  Data  and  applications  proliferated, 
with  little,  if  any,  control  or  standardization.  In  the  last 
few  years,  CNRF  has  experienced  this  dilemma  of  controlling 
end  user  computing  and  has  now  focused  the  use  of 
microcomputers  into  building  a  distributed  SELRES  database 
that  employs  data  structures  and  definitions  established 
within  the  new  IMAPMIS  database.  By  incorporating  information 
planning  into  the  organization's  long  range  goals,  CNRF  has 
directly  confronted  both  organizational  and 
centralization/decentralization  issues.  with  foresight  and 
resourcefulness,  CNRF  developed  RTSS  and  RSTARS,  a  framework 
that  provides  CNRF  with  centralized  strategic  control  of  a 
large  integrated  information  system  and  also  offers  geographic 
distribution  of  data  entry  and  processing  to  operational 
levels  (the  NRAs).  RTSS  gives  CNRF  demonstrated  capability 
to  maintain  a  centralized  master  database.  RSTARS  affords 
commanding  officers  access  to  and  the  ability  to  update  and 
manipulate  critical  SELRES  and  mobilization  data  on  a  daily 
basis  using  replicated  partitions  of  the  master  database. 
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Although  this  approach  may  not  be  the  most  efficient  method 
of  data  storage,  it  does  successfully  support  the  information 
needs  of  CNRF.  Data  is  input  at  the  NRAs  on  a  daily  basis  and 
uploaded  nightly  to  CNRF  via  modem.  Once  inputs  are 
processed,  the  master  database  in  New  Orleans  is  the  most 
current,  most  accurate  database  pertaining  to  SELRES  and 
mobilization  billet  structures.  Additionally,  this 
distribution  solution  affords  a  maximum  level  of  backup 
capability  in  the  event  of  a  loss  of  the  master  database. 
Other  factors,  such  as  cost  of  communications  and  methods  of 
update  are  the  most  efficient  and  effective  possible  given 
the  equipment  and  budgets  available. 

While  the  centralized  management  and  control  approach  of 
IMAPMIS  ideally  supports  the  administrative,  record-keeping 
mission  of  NRPC,  it  is  unacceptable  for  the  needs  of  CNRF. 
The  decentralized,  distributed  structure  of  RTSS  and  RSTARS 
more  adequately  supports  the  operational  requirements  of  CNRF. 

C.  DATA  OWNERSHIP 

The  central  question  still  remains  unanswered:  who  really 
owns  the  SELRES  data?  Is  it  NRPC,  tasked  with  maintaining  the 
records  for  all  inactive  assets,  or  is  it  CNRF  who  actively 
uses  and  manipulates  both  personnel  and  mobilization  billet 
data. 
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In  the  early  days  of  computerized  data  processing,  most 
systems  were  clerical  in  nature.  Input,  processing,  output 
and  storage  functions  were  all  the  centralized  responsibility 
of  a  single  department.  In  this  environment,  the  commonly 
accepted  belief  was  that  the  data  was  "owned11  by  the 
application  by  which  it  was  used.  The  department  that 

developed  these  applications  used  them  to  justify  budgets. 
Subsequently,  since  the  ADP  department  paid  for  the  system, 
they  owned  the  data. 

However,  with  the  introduction  of  database  systems,  data 
is  now  totally  independent  of  the  applications.  Data  is 
accessible  by  multiple  systems  and  multiple  users.  Logically, 
in  a  database  environment,  ownership  refers  instead  to  the 
accountability  of  an  individual  for  each  data  element.  The 
task  of  assigning  ownership  of  data  within  an  organization  is 
normally  coordinated  by  the  database  administrator  among  the 
various  users.  However,  since  IMAPMIS  is  external  to  the  true 
users  of  the  data,  there  is  little  coordination  between  the 
users  and  NRPC.  Therefore,  there  are  no  clearly  defined 
responsibilities  for  data  control  exist. 

For  example,  CNRF  is  responsible  to  the  Chief  of  Naval 
Operations  for  structuring  mobilization  billets  and  for 
training  and  administering  SELRES.  To  effectively  accomplish 
these  objectives,  CNRF  must  have  a  reliable,  accessible  and 
responsive  database  available  for  daily  transactions  and  use 
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in  formulating  management  decisions.  Alternatively,  IMAPMIS 
merely  reports  information  and  processes  updates  submitted  by 
CNRF.  In  many  cases,  data  submissions  by  CNRF  are  not 
accurately  updated  within  IMAPMIS  (CNRF  letter, 7  November 
1989).  Does  CNRF  own  the  data  or  does  NRPC?  The  answer 
depends  entirely  on  who  is  asked.  Surprisingly  however, 
within  the  present  IMAPMIS  system  architecture,  CNRF  has 
virtually  no  control  of  the  data  or  data  quality  that  directly 
affects  the  personnel  resources  he  is  responsible  for 
training . 

D.  DATA  QUALITY 

Data  quality  can  be  viewed  in  many  different  perspectives. 
These  encompass  data  integrity  (or  accuracy),  completeness, 
timeliness  and  currency,  and  origin.  Data  integrity  is 
perceived  as  a  joint  responsibility  between  the  users,  for 
actual  contents  and  values,  and  the  database  administrator, 
for  logical  data  structures  (Perry, 1983, p. 28 ) .  Control  of 
^ata  integrity  has  historically  been  a  constant  source  of 
irritation  between  CNRF  and  NRPC.  For  SELRES  assigned  to 
reserve  units,  quality  data  represents  timely,  accurate 
compensation  for  performed  training.  For  CNRF  it  provides 
comprehensive,  precise  information  about  unit  billet 
structures  and  the  associated  manning  and  training  levels  of 
assigned  personnel.  These  attributes  are  sorely  lacking 
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within  IMAPMIS,  which  seriously  restricts  the  ability  of  CNRF 
to  achieve  assigned  goals. 

One  major  difficulty  in  assessing  accuracy  of  data  within 
IMAPMIS  is  that  it  is  not  clear  how  all  of  the  data  is 
collected  or  input  or  which  source  of  data  dominates  others. 
With  the  numerous  interorganizational  interfaces  of  IMAPMIS 
and  the  volumes  of  input  and  output  tapes  used  in  processing, 
it  is  virtually  impossible  to  determine  which  system  overrides 
which  and  ultimately  ascertain  data  origins.  The  data 
contained  in  the  IMAPMIS  database  is  full  of  errors  and  in 
many  cases  incomplete. 

A  second  problem,  involves  error  detection.  The  lapse  of 
time  between  data  entry  and  error  detection,  has  a  direct  the 
complexity  of  data  correction.  If  errors  are  detected  at  the 
point  of  entry  by  built  in  edit  checks  and  validation,  then 
the  probability  of  correction  is  very  high.  Conversely,  if 
errors  are  not  found  for  several  weeks,  minimal  effort  and 
time  will  be  devoted  to  corrections  (Davis  and  Olson, 1985). 
Thus,  the  amount  of  time  taken  to  identify  errors  seriously 
affects  the  data  quality.  In  IMAPMIS,  where  errors  may  go 
undetected  for  weeks  or  even  months,  data  quality  problems 
abound  and  will  not,  in  all  likelihood,  improve. 

A  third  major  problem  in  IMAPMIS  is  the  result  of  a 
complete  lack  of  enforceable  standards  of  data  quality  for 
governmental  information  systems.  Most  directives  and 
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instructions  are  vague  and  ambiguous  ( La udon, January  1986). 
Without  adequate  guidelines  for  specifying  data  quality,  that 
quality  becomes  difficult  to  define  and  even  more  difficult 
to  enforce.  Further,  as  long  as  IMAPMIS  remains  a  large 
centralized  database  with  multiple  overlapping  processes, 
control  of  data  quality  will  continue  to  elude  system  managers 
no  matter  how  good  the  data  quality  is  at  the  point  of  entry. 

Most  authorities  on  database  quality  agree  that  data 
should  be  captured  and  entered  into  any  information  system  at 
its  source.  The  question  then  becomes ,  what  is  the  proper 
source  of  data.  It  is  the  contention  of  this  thesis,  that  the 
best  source  of  data  for  an  individual  SELRES  is  the  NRA  where 
the  member  drills.  Similarly,  the  authoritative  origin  of 
unit  structures  should  come  from  CNRF  and  not  be  overturned 
by  IMAPMIS  edits.  Therefore,  the  data  being  input  to  IMAPMIS 
at  the  NRAs  and  through  RTSS  is  in  fact,  the  most  recent, 
accurate  data  available.  Further,  this  data,  once  validated 
by  entry  edit  checks  should  be  considered  by  all  other  systems 
as  the  data  against  which  other  data  elements  should  be 
compared  and  updated.  Presently,  the  system  operates  exactly 
the  opposite  with  newly  input  data  from  the  NRAs  being 
compared  to  data  already  in  the  IMAPMIS  database. 

The  validation  and  edit  checks  completed  at  entry  and  at 
the  CNRF  level  are  sufficient  to  ensure  that  data  is  correctly 
updated.  As  the  users  "are  made  responsible  for  entering 
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their  own  data  and  for  the  accuracy  of  those  data,  the  number 
of  errors  drops  greatly..."  (Martin, 1981 ) .  Data  entry, 
performed  by  local  personnelmen  or  civilians  who  understand 
what  the  data  means,  will  also  help  ensure  the  completeness 
and  timeliness  of  the  data  and  subsequently  improve  the 
accuracy  and  quality  of  the  master  database.  Although  these 
functions  are  being  accomplished  now  at  the  NBAs,  IMAPMIS 
interface  edits  that  create  high  'olumes  of  transaction 
rejections  only  serve  to  intensify  the  adversarial 
relationship  between  CNRF  and  NRPC.  This  is  usually  reflected 
in  the  attitude  that  "It's  not  my  fault  that  things  are 
screwed  up:  the  computer  did  it". 

E.  DATA  AND  SYSTEM  INTERFACES/INTEROPERABILITY  CONCERNS 

Interoperability  is  the  ability  to  share  resources  through 

planned  compatibility  of  technical  resources;  and  further  to 

use  these  capabilities  to  support  functional  requirements  in 

the  most  effective  and  cost  efficient  manner  possible 

( OPNAVINST  5230.22,6  October  1986). 

It  is  extremely  important  that,  in  exchanges  of  automated 
data,  the  one  receiving  the  data  has  the  same 
interpretation  as  the  one  sending  it.  This  understanding 
is  directly  related  to  the  definition  of  the  data  elements 
and  the  values  of  the  data  codes.  (DOD  500. 12-M, October 
1985, p. 5) 

Due  to  original  design  of  IMAPMIS  and  poor  documentation,  the 
numerous  internal  and  external  system  interfaces  are  ill- 
defined.  As  previously  discussed,  in  CNRF  correspondence  to 
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CNRF  (CNRF  letter ,14  November  1989)  the  immediate  need  to 
correct  these  interface  problems  was  fervently  reiterated. 
SDP  III  also  recognized  the  necessity  for  the  upgrade  of 
system  and  process  interfaces.  Although  major  efforts  have 
been  dedicated  within  the  Navy  to  develop  standardized  data 
definitions  and  structures,  those  incorporated  into  the  many 
IMAPMIS  subsystems  have  not  yet  been  updated,  and  may  or  may 
not  conform  to  these  standards. 

With  these  problems  in  mind,  it  is  easy  to  understand  the 
antagonism  between  IMAPMIS  program  administrators  and  the  data 
users.  For  the  users,  who  are  trying  to  maintain  a  quality 
database,  it  is  frustrating  to  explain  to  a  SELRES  that  he/she 
will  not  be  paid  for  their  previous  drills  because  a  hidden 
edit  within  IMAPMIS  has  rejected  a  valid  transaction.  No  one 
seems  to  have  a  firm  understanding  of  which  system  overrides 
another  or  who  is  ultimately  responsible. 

F.  LEGAL  CONSIDERATIONS 

In  addition  to  the  operational  issues  addressed  above, 

there  are  also  legal  ramifications  to  the  present  state  of 

IMAPMIS.  The  Privacy  Act  of  1974  imposed  a  legal  obligation 

that  all  computerized  record  systems  must: 

...maintain  all  records  which  are  used  by  the  agency  in 
making  any  determination  about  any  individual  with  such 
accuracy  relevance,  timeliness  and  completeness  as  is 
reasonably  necessary  to  assure  fairness  to  the  individu¬ 
al...  (P.  L.  93-579:  The  Privacy  Act  of  1974) 
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Thus,  information  systems  containing  inaccurate,  incomplete, 
ambiguous  information  not  only  violate  individual's  rights, 
they  are  technically  illegal. 

6.  SUMMARY 

The  problem  within  IMAPMIS  then  becomes  one  of  how  to  best 
resolve  both  management  issues  and  the  operational 
inadequacies.  Constant  struggles  at  CNRF  to  control  the  data 
quality  and  ensure  compliance  with  applicable  statutes  are  met 
with  resistance  at  NRPC.  IMAPMIS  developers,  concentrating 
on  administrative  problems  are  occupied  with  an  almost 
insurmountable  challenge  of  transitioning  IMAPMIS  into  a 
modern,  responsive  system.  Under  existing  centralized 
management  control  policies  and  focus  on  NRPC  mission 
objectives,  CNRF  will  not  receive  any  relief  in  the 
foreseeable  future.  Alternatives  must  be  examined  that  will 
support  the  future  needs  of  both  CNRF  and  NRPC.  These  needs 
should  be  pursued  independently  with  NRPC  continuing  with 
IMAPMIS  redesign  emphasis  on  non-SELRES  applications;  and  that 
CNRF  forge  on  with  expansion  of  RTSS  and  RSTARS,  assuming 
management  responsibility  of  the  mobilization  billet  and 
SELRES  database. 

In  the  following  chapter,  a  revised  data  flow  architecture 
will  be  proposed  that  will  provide  a  faster,  more  reliable 
alternative  to  awaiting  future  improvements  to  IMAPMIS.  These 
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enhancements,  that  will  surely  be  insufficient  for  CNRF 
information  needs  are  a  classic  case  of  too  little,  too  late. 
The  feasibility  of  establishing  the  SELRES  database  at  CNRF 
and  the  emergent  data  flows  it  creates  will  be  discussed. 
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IV.  RECOMMENDED  DATAFLOW  ARCHITECTURE 


It  is  common  knowledge  within  the  Naval  Reserve  Force  that 
IMAPMIS  is  incapable  of  supporting  the  current  information 
needs  of  CNRF.  In  fact,  as  far  back  as  1983  system  planners 
wrote  that: 

The  redesign  and  rewrite  of  IMAPMIS  is  the  most  compelling 
need  of  all  Inactive  Requirements  as  the  present  system 
is  the  basic  cause  of  numerous  problems  cited  daily  by 
users  at  all  levels.  (IMAPMIS  SDP  1,1983) 

Since  little  has  changed,  it  is  now  time  to  consider 

significant  changes  to  the  way  SELRES  data  is  controlled  and 

processed. 

In  regard  to  the  inadequacies  of  IMAPMIS  discussed  in  the 
previous  chapters,  it  is  strongly  recommended  that  maintenance 
responsibility  for  the  SELRES  and  Mobilization  Billet  database 
be  removed  from  IMAPMIS/NRPC  management  and  transferred  to 
CNRF  control.  As  has  been  previously  mentioned,  however, 
IMAPMIS  is  and  will  continue  to  be,  under  the  auspices  of 
NMPC,  the  official  corporate  repository  for  all  Inactive 
Reserve  data.  Therefore,  through  the  RTSS/IMAPMIS  interface 
and  PAYPERS  processing,  the  CNRF  database  will  continue  to 
feed  periodic  data  updates  to  IMAPMIS  to  satisfy  currency  and 
external  reporting  requirements.  This  approach  will 
successfully  support  improved  data  quality  for  both  CNRF  and 
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IMAPMIS,  minimize  the  need  for  changes  in  system  interfaces, 
promote  modular  management  information  application 
development,  and  provide  the  information  system  structures 
that  best  suit  both  CNRF  and  NRPC. 

In  this  chapter,  the  actual  changes  in  data  flows  that 
result  from  the  new  architecture  as  well  as  each  of  the 
improvements  mentioned  above  will  be  discussed. 

A.  CHANGES  IN  INFORMATION  DATA  FLOWS 

The  Information  flows  that  existed  in  IMAPMIS  prior  to  the 
introduction  of  RSTARS  and  the  direct  interface  between  NMD AS 
and  RTSS  are  provided  in  Figure  5.  Even  with  these 
improvements,  many  of  the  old  data  flows  continued  to  exist 
as  NRAs  began  using  RSTARS  and  discontinued  submission  of 
diary  entries  directly  to  NRPC  for  input  to  IMAPMIS. 
Additionally,  although  RTSS  is  scheduled  to  receive  billet 
data  from  OPNAV,  CNRF  must  still  submit  hardcopy  unit 
structures  to  NRPC  for  input  to  IMAPMIS  for  production  of 
official  unit  manning  and  readiness  reports. 

As  can  be  noted  from  Figure  5,  the  number  of  organizations 
and  internal  and  external  systems  that  input  data  directly  to 
NRPC  imposed  a  tremendous  burden  on  personnel  and  the  system 
interfaces.  With  419  NRAs  submitting  personnel  and  drill  data 
on  approximately  131,000  SELRES  in  addition  to  non-SELRES 
data  requirements,  both  NRPC  and  IMAPMIS  struggled  to  sustain 
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Figure  5.  Existing  SELRES  Data  Flow  Architecture 
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existing  levels  of  quality.  Additionally,  Figure  5  suggests 
the  tremendous  amount  of  data  that  was  merely  passed  from  one 
source  to  another  with  little  processing.  Specific  examples 
include: 

1.  The  passage  of  unit  structures  from  CNRF  to  NRPC  for 
input  into  IMAPMIS.  Once  input,  unit  reports  were 
generated  and  forwarded  to  the  NRAs 

2.  Personnel  data,  billet  assignments,  and  drill 
participation  data  were  submitted  to  NRPC.  Drill 
chits  and  paper  OCR  documents  were  scanned  to  generate 
data  tapes  that  were  forwarded  for  processing  with 
IMAPMIS  updates 

3.  Unit  authorizations  from  Director  of  Naval  Reserve 
were  sent  to  NRPC  to  either  establish  or  discontinue 
reserve  units.  The  information  was  input  to  IMAPMIS 
by  NRPC  personnel 

4.  ACDUTRA  completion  data  was  also  passed  to  NRPC  from 
PSDs  for  input  to  IMAPMIS  and  eventual  update  of 
participation  point  credit 

These  are  only  a  few  of  the  examples  of  data  passing  and  the 
volume  of  transactions  that  were  imposed  on  the  NRPC  staff. 

Figure  6  illustrates  a  revised  information  flow 
architecture  with  full  implementation  of  the  NMDAS-RTSS 
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REVISED  SELRES  DATA  FLOW  ARCHITECTURE 


Figure  6.  Revised  SELRES  Data  Flow  Architecture 
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interface  and  transfer  of  the  SELRES /Mobilization  database  to 
CNRF  responsibility.  This  simplified  data  flow  will  allow 
field  activities  to  submit  all  personnel,  billet  assignments, 
drill  participation  and  ACDUTRA  data  electronically  to  the 
central  CNRF /RTSS  database.  Adequate  validity  and  edit  checks 
are  incorporated  at  both  the  NRA  and  the  CNRF  level  to  ensure 
that  data  elements  are  correct  and  correspond  to  acceptable 
values  and  structures.  Since  data  uploads  and  downloads  are 
accomplished  on  a  daily  basis  between  each  NRA  and  CNRF,  the 
database  is  up-to-date  and  accurate  within  a  24-hour  period. 
Data  is  no  longer  simply  passed  among  commands  awaiting  entry 
or  processing. 

B.  CNRF  MANAGEMENT  CONCERNS 

The  transition  of  a  flat-file  system  to  database 
technology  is  not  merely  a  change  in  applications,  it  requires 
a  change  in  management  philosophy.  CNRF  has  recognized  the 
value  of  information  as  a  strategic  resource  and  has 
incorporated  it  into  command  long-term  objectives.  In  recent 
years,  with  the  development  of  RTSS  and  RSTARS ,  CNRF  has 
established  a  distributed  information  system  that  supports 
commanding  officers  in  the  field  with  local  SELRES  and 
mobilization  billet  data  as  well  as  proving  a  centrally 
controlled  database  that  is  accessible  and  accurate.  With 
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these  resources  totally  under  CNRF  control,  more  effective 
and  efficient  decisions  regarding  mission  accomplishment. 


C.  APPLICATION  DEVELOPMENT  AND  MANAGEMENT  INFORMATION 
APPLICATIONS 

Some  of  the  major  objectives  of  using  database  technology 
are  to  speed  up  application  development,  generate  better 
documentation,  and  reduce  application  maintenance  costs. 
Applications  for  the  RTSS/RSTARS  systems  are  being  developed 
in  a  modular  approach  and  using  higher  level  languages  that 
simultaneously  support  navy  directives  and  also  significantly 
reduce  development  time  and  costs  through  the  use  of 
prototyping. 

Future  applications  will  also  include  management  support 
programs,  to  include  decision  support  systems  (DSS),  that  will 
enhance  the  ability  of  CNRF  to  more  effectively  and 
efficiently  use  limited  resources  to  achieve  major  operational 
goals . 

D.  SYSTEM  INTERFACES 

The  only  interfaces  that  will  change  among  the  many 
organizations  and  systems  with  the  revised  information  flow, 
will  be  the  establishment  of  a  direct  link  capability  between 
RTSS  and  PAYPERS.  By  initiating  this  interface,  RTSS  data 
can  be  transmitted  directly  to  PAYPERS  for  processing  against 
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and  with  IMAPMIS  tapes.  This  interface  eliminates  the  need 
to  hand-carry  data  tapes  to  NRPC  who  must  then  schedule  the 
bulk  data  transfers  using  EPMAC  facilities. 

With  the  already  existent  capability  to  download  billet 
requirement  data  from  NMDAS,  no  new  interfaces  need  be 
established  with  OPNAV.  This  interface,  which  became 
effective  in  October  1989,  has  proven  beneficial  in  both 
enhancing  timeliness  in  receiving  updated  mobilization 
requirements  and  the  ability  of  CNRF  to  more  quickly  structure 
reserve  units. 

The  interface  between  RTSS  and  IMAPMIS  already  exists  and 
should  not  change  other  than  to  correct  edit  and  validation 
problems  that  have  already  been  identified.  Even  though  the 
SELRES  data  may  be  controlled  by  CNRF,  it  is  still  vital  that 
the  data  be  transmitted  to  the  NRPC  data  repository. 

In  the  future,  it  will  no  longer  be  necessary  for  NRPC 
to  receive  an  enlisted  or  officer  service  record  in  house  and 
a  member  record  be  established  before  the  member  can  be 
affiliated  in  the  Naval  Reserve.  New  member  information  can 
be  verified  on  the  PAYPERS  system  during  processing  to  ensure 
that  the  individual  was  a  loss  to  active  duty  and  to  preclude 
allowing  an  individual  to  affiliate  with  more  than  one 
service.  After  this  verification  is  complete,  the  member 
should  be  eligible  for  participation  and  pay. 
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B.  BUNDLED  TRANSACTIONS 


In  regards  to  bundled  transactions,  RTSS  development 
efforts  should  attempt  to  design  an  application  modification 
that  will  accept  a  single  entry,  such  as  an  advancement  or 
unit  transfer,  and  automatically  generate  the  prerequisite 
entry  for  discharge  or  detachment  from  a  previous  unit.  This 
will  eliminate  the  need  for  dual  entries  to  accomplish  a 
single  personnel  change.  If  it  is  possible  to  tie  the 
generated  entry  with  the  original  entry,  this  may  also 
alleviate  the  parallel  processing  problems  encountered  with 
the  PAYPERS  hardware  suite. 

F.  DATA  OWNERSHIP  AND  IMPROVED  DATA  QUALITY 

As  discussed  in  chapter  four,  in  order  to  enhance  data 
quality,  data  should  be  entered  at  its  source,  and  personnel 
who  input  the  data  should  be  held  directly  responsible  for  the 
quality.  Today,  the  accuracy  and  quality  of  the  CNRF  database 
on  SELRES  is  far  superior  to  that  of  the  database  maintained 
by  NRPC .  Once  the  data  flow  architecture  is  revised,  the  data 
quality  of  IMAPMIS  becomes  the  sole  responsibility  of  CNRF. 
The  data  then  should  become  the  standard  against  which  other 
data  is  compared  and  updated  as  necessary.  No  longer  will  the 
tail  be  wagging  the  dog,  but  the  accurate  SELRES  data  will 
update  IMAPMIS.  From  the  perspective  of  CNRF,  there  will  be 
little  change  in  business  with  the  exception  that,  when  a 
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correct  and  valid  data  entry  is  put  into  the  database,  there 
should  be  no  external  interface  or  processing  requirement  that 
will  reject  the  transaction.  Thus,  in  addition  to  betterment 
in  CNRF  performance  and  decision  quality,  there  should  be 
significant  improvements  in  data  reported  to  external  sources. 
This  will  ultimately  precipitate  better  policy  and  budget 
decisions  in  behalf  of  the  Naval  Reserve  Force. 

G.  SUMMARY 

In  summary,  by  transferring  the  SELRES/Mobilization  Billet 
database  to  CNRF  control,  many  of  the  management  issues 
previously  addressed  and  the  operational  problems  of  IMAPMIS 
will  be  circumvented.  NRPC  program  developers  can  then 
concentrate  their  future  application  efforts  to  those 
processes  and  interfaces  that  directly  impact  on  the 
management  of  non-SELRES  personnel. 

In  chapter  five,  a  brief  summary  of  the  inherent  problems 
of  IMAPMIS  will  be  given,  and  followed  by  a  synopsis  of  the 
effects  that  the  revised  information  flow  architecture  will 
have  on  resolving  these  problems. 


82 


V.  CONCLUSIONS 


Despite  the  fact  that  IMAPMIS  is  an  antiquated  system  full 
of  errors  and  unresponsive  to  either  CNRF  or  NRPC  information 
requirements,  NRPC  is  still  responsible  for  maintaining  the 
Navy's  corporate  Inactive  Naval  Reserve  database.  The 
original  design  and  applications  of  IMAPMIS  cannot  be  modified 
to  efficiently  support  the  new  relational  database. 
Therefore,  all  applications  and  interfaces  must  be  carefully 
examined,  evaluated  and  redesigned  before  any  improvements 
will  be  noticeable.  Further,  the  differences  in 
organizational  goals  of  NRPC  and  CNRF  provide  little  common 
ground  for  future  agreement  on  priorities  for  improvements  or 
uses  of  IMAPMIS. 

To  compensate  for  the  poor  support  of  IMAPMIS,  and  in  an 
attempt  to  provide  some  internal  command  controls,  CNRF 
developed  his  own  database  to  more  closely  suit  strategic  and 
operational  information  requirements.  Although  this  system 
(RTSS)  is  highly  effective  and  used  throughout  the  Naval 
Reserve  Force,  it  still  has  not  been  permitted  to  solve  any 
of  the  basic  management  and  quality  problems  inherent  to 
IMAPMIS.  RTSS  and  RSTARS,  the  only  data  input  sources  for 
SELRES  data  were  designed  to  control  data  redundancy,  and 
ensure  the  timeliness  and  completeness  of  data.  Even  with 
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CNRF  achievements  in  maintaining  an  accurate  database, 
frequent  IMAPMIS  data  overwrites  and  transaction  rejections 
generated  by  antiquated  edit  and  validity  checks  prove 
counterproductive.  Sources  of  transaction  rejections  are 
virtually  impossible  to  isolate  and  continue  to  hinder 
relationships  between  CNRF  and  NRPC. 

Without  control  of  SELRES  data,  CNRF  has  failed  to 
positively  affect  the  quality  of  IMAPMIS.  However,  major 
innovative  improvements  have  resulted  from  the  development  of 
RTSS  and  RSTARS.  During  the  same  time-frame  as  phase  one  of 
IMAPMIS,  CNRF  introduced  microcomputers  to  NRAs  and  during  the 
last  year,  has  successfully  transitioned  from  the  archaic, 
time-consuming  practice  of  updating  SELRES  data  with  OCR 
documents  mailed  to  NRPC  for  scanning,  to  modern  interactive 
data  update  and  electronic  data  transfer  capabilities.  With 
the  advantage  of  being  able  to  design  a  new  system  rather  than 
being  constrained  by  trying  to  redesign  an  old  system,  CNRF 
was  able  to  use  a  modern,  modular  development  approach.  The 
result  is  a  highly  successful,  state  of  the  art,  distributed 
data  system  that  is  easy  to  use  and  update.  The  use  of  high 
level  languages  and  incorporation  of  microcomputers  into  the 
overall  system  architecture  has  earned  widespread  acceptance. 
Use  of  application  generators  for  module  development  has 
enhanced  documentation  and  ensured  lower  cost,  more  easily 
maintained  applications.  Additionally,  RTSS  and  RSTARS  lend 


84 


themselves  to  future  management  information  applications 
including  decision  support  systems  (DSS)  similar  to  that  under 
development  for  mobilization  billet  structuring. 

This  proposal,  to  extract  the  SELRES  and  mobilization 
billet  database  from  NRPC  responsibility,  and  to  use  the  CNRF 
database  to  update  NRPC  records,  is  a  preferred  solution  to 
many  IMAPMIS -related  problems.  Data  quality  will  certainly 
improve  and  responsibilities  and  accountability  are  clearly 
defined.  CNRF  will  be  able  to  access  accurate  data  for 
analysis  and  support  of  internal  management  decisions.  And 
finally,  data  reported  by  IMAPMIS  to  external  sources  will 
more  accurately  reflect  the  true  status  of  the  Naval  Reserve 
Force  and  will  support  improved  policy  and  budget  decisions 
in  the  future. 
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APPENDIX  A 


GLOSSARY 


ACCPDS 

CDC 

DMDC 

EMF 

EPMAC 

FAD 

I  EMF 

IFILMAN 

IMAPMIS 

IOMF 

IOPAS 

IRIS 

MAD 

MANTIS 

MAPTIS 

NEOPS 

NES 

NMDAS 


Active  Component  Common  Personnel  Data  System  (DOp; 
Consolidated  Data  Center 
Defense  Manpower  Data  Center 
Enlisted  Master  File  (NMPC) 

Enlisted  Personnel  Manpower  Center  (NMPC) 

Foreign  Address  File  (NRPC) 

Inactive  Enlisted  Master  File  (NRPC) 

Inactive  File  Maintenance  (System)  (NRPC) 

Inactive  Manpower  and  Personnel  Management  Informa¬ 
tion  System  (NMPC/NRPC) 

Inactive  Officer  Master  File  (NRPC) 

Inactive  Officer  Promotion  Administrative  System 
(NMPC) 

Inactive  Remote  Inquiry  System  (NRPC) 

Master  Address  File  (US  Postal  Service) 
Programming  Language  used  with  CINCOM's  SUPRA 
Manpower  and  Personnel  Training  Information  System 
Navy  Enlisted/Officer  Participation  System  (NRPC) 
Navy  Enlisted  System  (NMPC) 

Navy  Manpower  Data  Accounting  System  (OPNAV) 
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GLOSSARY  (cont.) 


NRPDS 

NRURS 

OMF 

OPINS 

PERSPAY 

PH-PI 

PIMMS 

RCCPDS 

RESFIRST 

RESFMS 

RTSS 

RUAD 

RUMAS 

SOS 


Naval  Reserve  Drill  Pay  System  (NRPC) 

Naval  Reserve  Unit  Reporting  System  (NRPC) 

Officer  Master  File  (OMF) 

Officer  Personnel  Information  System  (NMPC) 
Personnel  and  Payroll  System 
Promotional  History  Transaction 

Pretrained  Individual  Manpower  Management  System 
(NRPC) 

Reserve  Component  Common  Personnel  Data  System 
(DOD) 

Reserve  Field  Information  Reporting  System  (NRPC) 
Reserve  Financial  Management  System  (NRPC) 

Reserve  Training  Support  System  (CNRF) 

Reserve  Unit  Assigned  Document 

Reserve  Unit  Manpower  Authorization  System  (NRPC) 
Source  Data  System  (NMPC) 
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